Привет всем!
Решил обсудить с вами процесс получения информации у заказчика о
бизнес-процессах в его предметной области!
С чего начать опрос о существующих бизнес-процессах?
На какие этапы или ступени разбить процесс выяснения?
Какого характера нужно задавать вопросы?
Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?
Спасибо всем, кто решится ответить.
21.05.05 17:22: Перенесено модератором из 'Философия программирования' — AndrewVK
22.05.05 01:39: Перенесено модератором из 'Shareware и бизнес' — retalik
Мне кажется вужно применять испытанные средства... утюги, паяльники, отрезания пальцев. Но делать это нужно гуманно и демакратично, чтобы злвые языки не могули обвинить вас в черствости.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Бусел, Вы писали:
Б>С чего начать опрос о существующих бизнес-процессах?
Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме. Затем это всё тщательно анализируется, прикидывается предварительная модель системы, и только потом начинается её обсуждение и уточнение с заказчиком. Всё это очень здорово экономит время как заказчика так и разработчиков.
Желательно получить не просто бланки, а реальные документы с реальными данными. Если это невозможно из соображений конфиденциальности, то вот здесь заказчику можно немножко попотеть и всё же предоставить какой-нибудь более менее правдоподобный вариант с Иван Ивановичами.
Бумажки также хороший способ верификации модели. Если, например, структура базы данных не позволяет получить какой-либо отчёт, то значит эта схема не верна.
Если нам не помогут, то мы тоже никого не пощадим.
Привет, весьма интересный ответ!
Забыл сказать, что я столкнулся с совершенно неизвестной мне областью.
Начал я с поиска в интернете информации для ликбеза, прочитал и .... что дальше-то.
Нужно вызывать на допрос заказчика, но с какой целью? IT>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме.
Образцы нужны, сгласен, но ведь нужно сперва выяснить с каким набором бумаг (документов)
сотрудник работает (каким-то образом относятся к теме). Следовательно, опрос первичен!
Но я так понял, что Вы предлагаете ДОПРОС №1 свести именно к краткому выяснению списка документов и их изьятию, правильно?
IT>Затем это всё тщательно анализируется,
Проанализировали образцы и видим, что не понятно 50% из них!
Не хватает ответа на ворос "Как получил сотрудник тот или иной документ?". IT>прикидывается предварительная модель системы,
Как можно прикидывать модель, если не известен бизнес-процесс создания этих образцов?
Еще не хватает информации о системе.
Какой на ваш взгляд?
И как ее получить?
Заказчик страдает путанным объяснением происходящего!
Нужна некая технология или способ ведения Допроса!
Как формулировать вопросы, чтобы полученный ответ был ценным?
А с остальным согласен!!! Пока остановились на дополнительном Допросе!
Здравствуйте, Бусел, Вы писали:
Б>Привет всем! Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
Б>С чего начать опрос о существующих бизнес-процессах? Б>На какие этапы или ступени разбить процесс выяснения? Б>Какого характера нужно задавать вопросы? Б>Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?
--
В книге Джонс Дж. К. "Методы проектирования", 1986 среди других способов и методов формального проектирования можно найти подробное описание того, как надо интервьюировать пользователей.
Здравствуйте, Бусел, Вы писали:
Б>Привет всем! Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
Добрый день. Есть 2 существенно различных варианта.. развития событий.
1 В случае, если организация не использует четко определенных бизнес-процессов в своей деятельности или находится в стадии активного роста (бизнес-процессы существенно меняются) автоматизация выступает одним из инструментов организации бизнеса. Это достаточно тяжелый случай для автоматизирующего подразделения (или сторонней компании).
2 В случае, если заказчик "всего лишь" не может четко сформулировать требования вам придется помочь ему это сделать.
Б>С чего начать опрос о существующих бизнес-процессах? Б>На какие этапы или ступени разбить процесс выяснения?
Сначала необходимо получить общее представление о бизнесе, который ведет компания (или автоматизируемое подразделений). Определите ключевые виды деятельности заказчика (например, ведутся ли закупки, складской учет, продажи, доставка продукции). Познакомьтесь со списком подразделений компнии. Определите масштаб бизнеса. Дальнейшее заключается в декомпозиции полученной информации — детализируется каждый из видов деятельности. Проведите консультации с руководителями отделов, специалистами, ответственными за узкоспециальные операции в ходе которых прорисовывается иерархическая структура процессов.
Для документирования используйте, скажем, BPWin, который позволяет получить наглядную многоуровневую схему бизнес-процессов. Получите полный список формируемых в ходе бизнеса документов, отчетов (в бумажном виде и электронном), список входящих, подлежащих обработке и регистрации документов. Полезна запись бесед с представитедями заказчика на диктофон (по письменным описаниям не всегда удается воспроизвести ход обсуждения в точности, упускаются кажущиеся неважными детали).
Проработку вопросов следует вести иерархически — не стоит производить детализацию какого-либо процесса не получив информации по смежным (практически все процессы взаимопроникают и любая информация по одному будет неполной без знания остальных).
Б>Какого характера нужно задавать вопросы?
Вопросы следует задавать непосредственно относящиеся с вопросу обсуждения . Например, "Какой объем документов ежедневно формируется отделами?", "Требуется ли экспорт отчетов в excel или html?", "Требуется ли удаленный доступ к системе (заказчиками или торговыми представителями)?". Недопустимы вопросы типа "Какой процент продаж установлен для агента на итальянском рынке?" — вопросы, не относящиеся к теме автоматизации.
Б>Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?
Хитро отвечаьт не нужно. Если вы считаете необходимым получить ту или иную информацию, вы должны уметь четко объяснить, для чего вам это нужно. Если объяснить не получается — видимо, вопрос не имеет смысла.
Б>Спасибо всем, кто решится ответить.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Бусел, Вы писали:
IT>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает.
ИМХО, "поговорить", все-же, надо. Ситуация: вы приходите в незнакомую компанию, собираете все бумажки, и..??? Пытаетесь восстановить по ним, чем-же все-таки эта контора занимается? Наверное, нужно прояснить структуру бизеса, для начала. А изучение первички, форм отчетности и т.п. — один из аспектов, но не единстенный.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Бусел, Вы писали:
Б>>С чего начать опрос о существующих бизнес-процессах?
IT>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме. Затем это всё тщательно анализируется, прикидывается предварительная модель системы, и только потом начинается её обсуждение и уточнение с заказчиком. Всё это очень здорово экономит время как заказчика так и разработчиков.
Вообще, активно общаться с заказчиком нужно на протяжении всего цикла разработки, особенно в начале. Любые документы в ходе работы подвергаются трактовке и анализу сотрудниками компании. Обязательно нужно знать, как используется тот или иной отчет, в какой последовательности возникают документы. Чем руководствуется сотрудник оформляющий, скажем, скидку, а не кредитноту в схожих ситуациях.
Здравствуйте, Бусел, Вы писали:
IT>>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме.
Б>Образцы нужны, сгласен, но ведь нужно сперва выяснить с каким набором бумаг (документов) сотрудник работает (каким-то образом относятся к теме). Следовательно, опрос первичен! Б>Но я так понял, что Вы предлагаете ДОПРОС №1 свести именно к краткому выяснению списка документов и их изьятию, правильно?
Точно.
IT>>Затем это всё тщательно анализируется, Б>Проанализировали образцы и видим, что не понятно 50% из них!
Ты думаешь тебе будет больше понятно если просто проведёшь интервью?
Б>Не хватает ответа на ворос "Как получил сотрудник тот или иной документ?".
Вот когда ты пойдёшь интервьюировать его второй раз об это можно будет и спрость.
IT>>прикидывается предварительная модель системы, Б>Как можно прикидывать модель, если не известен бизнес-процесс создания этих образцов? Б>Еще не хватает информации о системе. Б>Какой на ваш взгляд? Б>И как ее получить? Б>Заказчик страдает путанным объяснением происходящего! Б>Нужна некая технология или способ ведения Допроса! Б>Как формулировать вопросы, чтобы полученный ответ был ценным?
Начинать нужно с обработки документов, а не с интервью именно потому, что у тебя нет для первого интервью никаких вопросов, что приводит к пустой трате времени. Первое интервью обычно сводится к тому что разработчик и заказчик сидят друг против друга и молча смотрят друг на друга испепеляющими взглядами. Затем разработчик спрашивает:
— Ну и как вы тут ведёте бизнес?
— Нормально ведём, а что конкретно интересует?
— Ну, например, интересует как вы конкретно бизнес ведёте, детали всякие. Что автоматизировать будем?
— Да вот его бизнес автоматизировать и будем...
Короче, всё как обычно.
А теперь представь, что тебе что-то не понятно в бумажках, которые ты просмотрел. Какие у тебя будут вопросы? Правильно, конкретные.
— Я не понял, что это за цифра вот в этом отчёте. Она вообще тут нужна?
— Ну как же, это же... (рассказ на 30 минут что и как они делают).
— А вот эти данные откуда взяты.
— Ну у нас есть специальный классификатор и баба Маня, которая... (ещё 30 минут).
— А вот эти данные кто вводит?
— Это у нас есть отдел ввода этих данных, 150 человек, которые... (ещё 30 минут).
и т.п.
Т.е. то что тебе что-то не будет понятно, это нормально, и это как раз главная цель сбора бумаг — получить вопросы не тратя своё время и время заказчика.
ЗЫ. Насчёт самого интервью. Желательно его проводить вдвоём. Один задаёт вопросы, другой записывает всё что услышит. Затем всё это вдвоём представляют в виде отчёта, диаграмм и т.п.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, g_i, Вы писали:
IT>>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает.
g_i>ИМХО, "поговорить", все-же, надо. Ситуация: вы приходите в незнакомую компанию, собираете все бумажки, и..??? Пытаетесь восстановить по ним, чем-же все-таки эта контора занимается? Наверное, нужно прояснить структуру бизеса, для начала. А изучение первички, форм отчетности и т.п. — один из аспектов, но не единстенный.
Я к тому, что разговор после изучения бумажек будет в разы гораздо более эффективный.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали:
IT>>>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает.
g_i>>ИМХО, "поговорить", все-же, надо. Ситуация: вы приходите в незнакомую компанию, собираете все бумажки, и..??? Пытаетесь восстановить по ним, чем-же все-таки эта контора занимается? Наверное, нужно прояснить структуру бизеса, для начала. А изучение первички, форм отчетности и т.п. — один из аспектов, но не единстенный.
IT>Я к тому, что разговор после изучения бумажек будет в разы гораздо более эффективный.
Не согласен. Без предварительного обсуждения изучение бумажек затянется. Ибо это сродни реинженирингу (часто путанного) кода без тех. документации. Обследование должно начинаться с общения. ИМХО.
PS То, что изучение бумажек необходимо — это бесспорно.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали:
IT>>>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает.
g_i>>ИМХО, "поговорить", все-же, надо. Ситуация: вы приходите в незнакомую компанию, собираете все бумажки, и..??? Пытаетесь восстановить по ним, чем-же все-таки эта контора занимается? Наверное, нужно прояснить структуру бизеса, для начала. А изучение первички, форм отчетности и т.п. — один из аспектов, но не единстенный.
IT>Я к тому, что разговор после изучения бумажек будет в разы гораздо более эффективный.
Если не утверждается, что начинать нужно именно с изучения бумажек — тогда согласен.
Здравствуйте, g_i, Вы писали:
g_i>Если не утверждается, что начинать нужно именно с изучения бумажек — тогда согласен. g_i>
Именно это и утверждается. Экскурсии по предприятию и знакомство с передовиками производства не в счёт. Я говорю о начале детального изучения предметной области.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали: IT>Именно это и утверждается. Экскурсии по предприятию и знакомство с передовиками производства не в счёт. Я говорю о начале детального изучения предметной области.
Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.
Здравствуйте, Бусел, Вы писали:
Б>Привет всем! Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
Сначало надо понять для чего тебе нужна информация о заказчике.
Как правило она нужна для достяжения двух целей:
1) Определение границ системы автоматизации.
2) Моделирование (реализация) объектов и процессов в системе.
Даже если заказчик ваш коллега на предприятии — определение границ системы является необходимым этапом.
Советую начать работу с составления словаря предметной области. Как вы начнете свою работу в принципе все равно.
Это может быть интервью, опросники и т.д. Главное не вдаваться в детали с которых ты будешь плавать, а задавать наводящие вопросы. Ключевые объекты предметной области д.б. записаны и образованны основные связи между ними.
Дальше можно как угодно долго работать с этими терминами. Будет ли присутствовать объект в системе? Как реализован объект в виде документов? Это очень важно. ВАМ НЕ ОБЯЗАТЕЛЬНО ЗНАТЬ ПРЕДМЕТНУЮ ОБЛАСТЬ. Важно разговаривать в терминах предметной области.
Как правило работнику более понятны связи по управлению. Типа имею такой то документ ДЕЛАЮ ТО-ТО получаю такие-то изменения и новые документы. Более сложные связи типа ЧАСТЬ-ЦЕЛОЕ, ОБЩЕЕ-ЧАСТНОЕ обсуждать надо акуратно, как правило работник в них плавает. Пример, обсуждение что СЧЕТ состоит из заголовка СЧЕТА и ДЕТАЛЕЙ приводит работника в ступор.
Здравствуйте, Бусел, Вы писали:
Б>Привет всем! Б>Решил обсудить с вами процесс получения информации у заказчика о Б>бизнес-процессах в его предметной области!
Б>С чего начать опрос о существующих бизнес-процессах? Б>На какие этапы или ступени разбить процесс выяснения? Б>Какого характера нужно задавать вопросы?
Есть ГОСТ на создание автоматизированных систем — ГОСТ 34.602
AC>Советую начать работу с составления словаря предметной области. Как вы начнете свою работу в принципе все равно. AC>Это может быть интервью, опросники и т.д. Главное не вдаваться в детали с которых ты будешь плавать, а задавать наводящие вопросы. Ключевые объекты предметной области д.б. записаны и образованны основные связи между ними.
Да! Забыл добавить: необходимо включить в обсуждение ролей работников в системе. Сам термин РОЛЬ или АКТЕР лучше не употреблять. Должности и должностные инструкции тебе в помощь. После получения орг-штатной структуры у тебя появляется возможность получить информацию кто за что отвечает и кто что делает. Вопросы желательно задавать в разрезе МЫ ХОТИМ АВТОМАТИЗИРОВАТЬ, а не КАК ВЫ ЭТО ДЕЛАЕТЕ. Ответы на второй прямой вопрос ты получишь опосредованно.
AC>> Советую начать работу с составления словаря предметной области. Как AC>> вы начнете свою работу в принципе все равно. AC>> Это может быть интервью, опросники и т.д. Главное не вдаваться в AC>> детали с которых ты будешь плавать, а задавать наводящие вопросы. AC>> Ключевые объекты предметной области д.б. записаны и образованны AC>> основные связи между ними.
ac> Да! Забыл добавить: необходимо включить в обсуждение ролей ac> работников в системе. Сам термин РОЛЬ или АКТЕР лучше не ac> употреблять. Должности и должностные инструкции тебе в помощь. После ac> получения орг-штатной структуры у тебя появляется возможность ac> получить информацию кто за что отвечает и кто что делает. Вопросы ac> желательно задавать в разрезе МЫ ХОТИМ АВТОМАТИЗИРОВАТЬ, а не КАК ВЫ ac> ЭТО ДЕЛАЕТЕ. Ответы на второй прямой вопрос ты получишь ac> опосредованно.
На самом деле — нужно строить 2 модели — AS IS & TO BE. Как правило,
ресурсов хватает только на TO BE Поэтому ориентироваться на текущую
орг.структуру нужно только для создания базового плана бизнес-процессов. Как
правило, после прописания бизнес-процессов она иногда кардинально меняется
Yury Kopyl aka hrg | http://id.totem.ru |
"Если ты плюнешь на коллектив — коллектив утрется,
но если коллектив плюнет на тебя — ты утонешь" (С)Баралгин
Здравствуйте, g_i, Вы писали:
g_i>Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.
Буду начинать строить модель данных.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, g_i, Вы писали:
g_i>>Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.
IT>Буду начинать строить модель данных.
Нельзя строить модель неизвестно чего. Тебе выдали разобраный на детали механизм — без принципиальной схемы ты его либо не соберешь, либо соберешь не то. Модель данных у тебя получается — некая застывшая неупорядоченная схема, в ней не будут отражены (на старте) существенные связи и отношения. Динамические показатели системы во многом определяют структуру модели — а у тебя они поначалу вовсе не учитываются.
Я соглашусь с тобой в случае, если:
1 с набором первичных документов тебе выдали хотя бы общий список требований к системе
2 первичные документы и отчеты разбиты по неким функциональным группам и зафиксирофан определенный порядок их возникновения
Вообще, набор фактов поможет в случае, если имеется возможность сопоставить его с некой схемой — адекватно восстановить по нему исходную систему вряд-ли получится.