Привет всем!
Решил обсудить с вами процесс получения информации у заказчика о
бизнес-процессах в его предметной области!

С чего начать опрос о существующих бизнес-процессах?
На какие этапы или ступени разбить процесс выяснения?
Какого характера нужно задавать вопросы?
Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?

Спасибо всем, кто решится ответить.

Здравствуйте, Бусел, Вы писали:

Мне кажется вужно применять испытанные средства... утюги, паяльники, отрезания пальцев. Но делать это нужно гуманно и демакратично, чтобы злвые языки не могули обвинить вас в черствости.

Здравствуйте, Бусел, Вы писали:

Б>С чего начать опрос о существующих бизнес-процессах?

Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме. Затем это всё тщательно анализируется, прикидывается предварительная модель системы, и только потом начинается её обсуждение и уточнение с заказчиком. Всё это очень здорово экономит время как заказчика так и разработчиков.

Желательно получить не просто бланки, а реальные документы с реальными данными. Если это невозможно из соображений конфиденциальности, то вот здесь заказчику можно немножко попотеть и всё же предоставить какой-нибудь более менее правдоподобный вариант с Иван Ивановичами.

Бумажки также хороший способ верификации модели. Если, например, структура базы данных не позволяет получить какой-либо отчёт, то значит эта схема не верна.

Привет, весьма интересный ответ!
Забыл сказать, что я столкнулся с совершенно неизвестной мне областью.
Начал я с поиска в интернете информации для ликбеза, прочитал и .... что дальше-то.
Нужно вызывать на допрос заказчика, но с какой целью?
IT>Начинать нужно вообще не с опроса. Правильные пацаны первым делом отбирают у заказчика образцы всех бумаг с которыми он работает. Первичка, отчёты, накладные, любые бумажки, которые хоть каким-то образом относятся к теме.
Образцы нужны, сгласен, но ведь нужно сперва выяснить с каким набором бумаг (документов)
сотрудник работает (каким-то образом относятся к теме). Следовательно, опрос первичен!
Но я так понял, что Вы предлагаете ДОПРОС №1 свести именно к краткому выяснению списка документов и их изьятию, правильно?

IT>Затем это всё тщательно анализируется,
Проанализировали образцы и видим, что не понятно 50% из них!
Не хватает ответа на ворос "Как получил сотрудник тот или иной документ?".
IT>прикидывается предварительная модель системы,
Как можно прикидывать модель, если не известен бизнес-процесс создания этих образцов?
Еще не хватает информации о системе.
Какой на ваш взгляд?
И как ее получить?
Заказчик страдает путанным объяснением происходящего!
Нужна некая технология или способ ведения Допроса!
Как формулировать вопросы, чтобы полученный ответ был ценным?

А с остальным согласен!!! Пока остановились на дополнительном Допросе!

Здравствуйте, Бусел, Вы писали:

Б>Привет всем!
Б>Решил обсудить с вами процесс получения информации у заказчика о
Б>бизнес-процессах в его предметной области!

Б>С чего начать опрос о существующих бизнес-процессах?
Б>На какие этапы или ступени разбить процесс выяснения?
Б>Какого характера нужно задавать вопросы?
Б>Как хитро отвечать на вопрос заказчика "Зачем вам это нужно" ?
--
В книге Джонс Дж. К. "Методы проектирования", 1986 среди других способов и методов формального проектирования можно найти подробное описание того, как надо интервьюировать пользователей.

C уважением,
Геннадий Майко.

Здравствуйте, Бусел, Вы писали:

Б>Привет всем!
Б>Решил обсудить с вами процесс получения информации у заказчика о
Б>бизнес-процессах в его предметной области!

Добрый день. Есть 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>Это может быть интервью, опросники и т.д. Главное не вдаваться в детали с которых ты будешь плавать, а задавать наводящие вопросы. Ключевые объекты предметной области д.б. записаны и образованны основные связи между ними.

Да! Забыл добавить: необходимо включить в обсуждение ролей работников в системе. Сам термин РОЛЬ или АКТЕР лучше не употреблять. Должности и должностные инструкции тебе в помощь. После получения орг-штатной структуры у тебя появляется возможность получить информацию кто за что отвечает и кто что делает. Вопросы желательно задавать в разрезе МЫ ХОТИМ АВТОМАТИЗИРОВАТЬ, а не КАК ВЫ ЭТО ДЕЛАЕТЕ. Ответы на второй прямой вопрос ты получишь опосредованно.

alex-chin -> "Re[2]: Как вести ДОПРОС?" :


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 первичные документы и отчеты разбиты по неким функциональным группам и зафиксирофан определенный порядок их возникновения

Вообще, набор фактов поможет в случае, если имеется возможность сопоставить его с некой схемой — адекватно восстановить по нему исходную систему вряд-ли получится.

ИМХО.