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

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


hrg>На самом деле — нужно строить 2 модели — AS IS & TO BE. Как правило,
hrg>ресурсов хватает только на TO BE Поэтому ориентироваться на текущую
hrg>орг.структуру нужно только для создания базового плана бизнес-процессов. Как
hrg>правило, после прописания бизнес-процессов она иногда кардинально меняется
hrg>

Вообще то вопрос был как вести ДОПРОС. А именно как стоять на краю пропасти незнания ПО и не показаться профаном. Так что ASIS, то что надо. Ближе надо к юзверу... И по-ласковее...
А то что меняется после реинжиниринга — это разговоры в куринках — типа Кого сократят. И вообще мешать реинжениринг (а только поэтому может меняться ОШ структура) с автоматизацией не есть хорошо. Сначало как правило производится реинжениринг а уж потом... А сказки про реинжениринг вообще кто-то слышал?

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

hrg>> На самом деле — нужно строить 2 модели — AS IS & TO BE. Как
hrg>> правило, ресурсов хватает только на TO BE Поэтому
hrg>> ориентироваться на текущую орг.структуру нужно только для создания
hrg>> базового плана бизнес-процессов. Как правило, после прописания
hrg>> бизнес-процессов она иногда кардинально меняется

ac> Вообще то вопрос был как вести ДОПРОС. А именно как стоять на краю

ДОПРОС надо вести так, чтобы потом систему не переписывать

ac> Сначало как правило производится реинжениринг а уж потом... А сказки
ac> про реинжениринг вообще кто-то слышал?

Жизнь страшнее.

Yury Kopyl aka hrg | http://id.totem.ru | Только взял боец гитару, сразу
видно — гармонист...

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

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

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

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

Это важно. Будте готовы к тому, что руководители не знакомы (!) с бизнес процессами своей компании. Это нормально. Они, как сова из анекдота — о стратегии думают, и чаще всего не знают деталей бизнес-процессов. Но думают при этом, что знают, и введут вас в заблуждение. Руководители, конечно, бывают разные. Но они не обязаны разбираться в деталях, а язык неточно передает суть дела. Может очень уж неудобно получится, если этот нюанс выяснится при внедрении.

Иногда этот "нюанс" виден сразу. В моей практике один из директоров на просьбу в общих чертах описать схему товародвижения ответил вот что:
— Значит так. — вздох — Товар сначала поступает на Главный Виртуальный Склад...
И сразу мы понимаем, что нам трахают мозг, причем извращенным способом. Кстати, как я выяснил через 5 минут, "Главный Виртуальный Склад" — это сводный отчет по остаткам товаров на всех складах.

Мораль: не надейтесь узнать истину о бизнес-процессах в беседах с руководством заказчика. Это сложно, болезненно для обоих сторон, и даже иногда небезопасно для рассудка. Говорите с исполнителями.

Кстати, вам на заметку один нетрадиционный способ сорвать проект. После составления модели бизнес-процессов вы идете к начальникам отделов и показываете им схему. Так как они (см. предыдущий пункт) возможно впервые в подробностях узнали, как работает их отдел, у них чешутся руки и они затевают реорганизацию. Вас же просят подождать, пока все устоится. Или не просят, а просто начинают немедленно "оптимизировать" эти процессы. Это в большей степени относится к большим начальникам, вроде директоров.

Резюме: будте аккуратны, знакомя руководство заказчика со спецификацией бизнес-процессов. Подумайте, прежде чем предлагать улучшения в их схеме работы, это может затруднить вашу работу.

IT>Желательно получить не просто бланки, а реальные документы с реальными данными. Если это невозможно из соображений конфиденциальности, то вот здесь заказчику можно немножко попотеть и всё же предоставить какой-нибудь более менее правдоподобный вариант с Иван Ивановичами.
Обязательно именно заполненные бланки. Даже в очевидных (казалось-бы) случаях этого требовать необходимо. Уж очень неожиданные сюрпризы иногда вылезают.

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

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

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

hrg>>> На самом деле — нужно строить 2 модели — AS IS & TO BE. Как
hrg>>> правило, ресурсов хватает только на TO BE Поэтому
hrg>>> ориентироваться на текущую орг.структуру нужно только для создания
hrg>>> базового плана бизнес-процессов. Как правило, после прописания
hrg>>> бизнес-процессов она иногда кардинально меняется

ac>> Вообще то вопрос был как вести ДОПРОС. А именно как стоять на краю

hrg>ДОПРОС надо вести так, чтобы потом систему не переписывать

До следующей итерации... А по опыту следующая бывает через день

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

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

Ты так рассуждаешь, как будто я призываю один раз сходить к заказчику, забрать у него все бумажки, а потом сразу принести ему готовую систему

Главная идея всех этих бумажек в том, что придя второй раз к заказчику ты уже будешь задавать вполне конкретные вопросы, а следовательно получать вполне конкретные ответы. А это очень важно, хотя бы даже для того чтобы показать себя профессионалом, не говоря уже о бесполезной потере времени, пытаясь выковырять знания из людей, которых никто никогда не учил ими делиться и их формализовывать.

Бумажки — это прежде всего быстрый старт и начинать следует с них.

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

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

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

IT>Ты так рассуждаешь, как будто я призываю один раз сходить к заказчику, забрать у него все бумажки, а потом сразу принести ему готовую систему

Нет, я убежден, что следует начинать с получения представления (1) о предметной области на живом языке.

IT>Главная идея всех этих бумажек в том, что придя второй раз к заказчику ты уже будешь задавать вполне конкретные вопросы, а следовательно получать вполне конкретные ответы. А это очень важно, хотя бы даже для того чтобы показать себя профессионалом, не говоря уже о бесполезной потере времени, пытаясь выковырять знания из людей, которых никто никогда не учил ими делиться и их формализовывать.

Знания, достаточные для (1) всегда можно получить. Список бумажек не даст МНЕ представления о том, чем занимается компания — выставляет счета, регистрирует заявки, формирует расходно-приходные накладные, отчеты с непонятными названиями и цифрами — и что? Задавать вопросы навроде "Я так понимаю, это счет (нет, не счет? странно), он выставляется в момент отгрузки продукции.. Ах не в момент отгрузки? И не вы выставляете, а вам выставляют?" — разве не это пустая трата времени? Бумажки полезны для детализации схемы (МНЕ .

IT>Бумажки — это прежде всего быстрый старт и начинать следует с них.

Ты предпочитаешь начинать с модели данных — я с набросков потоков упреавления. Уверен, право на жизнь имеет более одного способа стартовать проект — личные предпочтения, привычки, опыт работы и склад ума в большой степени определяют выбор.

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

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

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

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

IT>>Ты так рассуждаешь, как будто я призываю один раз сходить к заказчику, забрать у него все бумажки, а потом сразу принести ему готовую систему

g_i>Нет, я убежден, что следует начинать с получения представления (1) о предметной области на живом языке.

Господа, спор на тему "с чего начинать анализ" имеет очень длинную историю, и многие уважаемые люди придерживаются противоположных точек зрения. Моя практика, к примеру, показывает, что начинать можно с чего угодно. Все равно процесс итеративный, и не слишком важно с чего начинать. Это вопрос сугубо личных предпочтений.

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

IT>>Ты так рассуждаешь, как будто я призываю один раз сходить к заказчику, забрать у него все бумажки, а потом сразу принести ему готовую систему

g_i>Нет, я убежден, что следует начинать с получения представления (1) о предметной области на живом языке.

На представлениях систему не сделаешь. Нужны конкретные знания и данные. А представление можно получить и по дороге в лифте с 1-го этажа на 9-й. Это не проблема.

g_i>Знания, достаточные для (1) всегда можно получить. Список бумажек не даст МНЕ представления о том, чем занимается компания — выставляет счета, регистрирует заявки, формирует расходно-приходные накладные, отчеты с непонятными названиями и цифрами — и что? Задавать вопросы навроде "Я так понимаю, это счет (нет, не счет? странно), он выставляется в момент отгрузки продукции.. Ах не в момент отгрузки? И не вы выставляете, а вам выставляют?" — разве не это пустая трата времени? Бумажки полезны для детализации схемы (МНЕ .

Ну вот только не надо так утрировать. Мы здесь все профессионалы, поднявшие не один проект. Зачем прикидываться первокурсником

IT>>Бумажки — это прежде всего быстрый старт и начинать следует с них.

g_i>Ты предпочитаешь начинать с модели данных — я с набросков потоков упреавления.

Потоков управления чем? Не данными ли?

g_i>Уверен, право на жизнь имеет более одного способа стартовать проект — личные предпочтения, привычки, опыт работы и склад ума в большой степени определяют выбор.

Меня на модели данных больше всего интересуют связи между объектами. Вот эти связи я и собираюсь выявлять с самого самого начала.

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

К тому же для моделирования потоков управления тебе всё равно нужны объекты. Соответственно, ты всё равно сначала, пусть неявно, в голове, строишь объектную модель. Так зачем себя и других обманывать

Я всегда стараюсь начать с разговора с конечным пользователем.
Очень сильно помогает

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

g_i>>Знания, достаточные для (1) всегда можно получить. Список бумажек не даст МНЕ представления о том, чем занимается компания — выставляет счета, регистрирует заявки, формирует расходно-приходные накладные, отчеты с непонятными названиями и цифрами — и что? Задавать вопросы навроде "Я так понимаю, это счет (нет, не счет? странно), он выставляется в момент отгрузки продукции.. Ах не в момент отгрузки? И не вы выставляете, а вам выставляют?" — разве не это пустая трата времени? Бумажки полезны для детализации схемы (МНЕ .

IT>Ну вот только не надо так утрировать. Мы здесь все профессионалы, поднявшие не один проект. Зачем прикидываться первокурсником

Я попытался описать конкретную ситуацию. Естественно, упрощенно, чтобы не оставить возможностей трактовки. Ты не ответил ни на один вопрос типа "Как ты это сделаешь?". Я пока не понял, что ты подразумеваешь под "анализом" первички. Выделение ключевых объектов — и все?

g_i>>Ты предпочитаешь начинать с модели данных — я с набросков потоков упреавления.
IT>Потоков управления чем? Не данными ли?
[skipped]
IT>Что касается потоков управления, то они не позволяют просто выразить общую картину предметной области. Для этого тебе понадобится несколько диаграмм для каждой подсистемы. Модель данных позволяет обойтись минимальным количеством диаграми, а для проведения танковых атак на глобусе мира вообще достаточно одной.

Несколько диаграмм — правильно. Но не горизонтально соседствующих, а иерархически. Каждая диаграмма содержит полную схему — отличаясь уровнями детализации. Модель данных (в моем представлении) не содержит динамики. Разверни схему процессов до полной детализации — получишь свою модель данных, но уже с "причинно-следственными" связями, правда без детализации сущностей.

IT>К тому же для моделирования потоков управления тебе всё равно нужны объекты. Соответственно, ты всё равно сначала, пусть неявно, в голове, строишь объектную модель. Так зачем себя и других обманывать

Пример. Опять утрирую, ты уж извини. "Сотрудник отдела по работе с клиентами получает заказ на продукцию. Обрабатывает его стандартным образом. Передает для согласования в производственную службу." Для того, чтобы описать данный блок совсем необязательно знать, что из себя представляет заказ — это детализируется позже. А вот от "заказа" без операций "принят", "обработан", "согласуется" с самого начала толку немного. На начальном этапе меня вполне устроят только наименования сущностей — "заказ" , "клиент", "счет", без детального описания. В дальшейшем я заинтересуюсь, что из себя представляет тот или иной документ, на следующем этапе анализа.

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

g_i>Пример. Опять утрирую, ты уж извини.

Стоп. Сейчас ты меня уташишь во флейм модель данных vs потоки управления.
Давай ка step back.

Мы здесь обсуждаем начало общения с заказчиком, первое интервью. Так? Вот давай это и обсуждать. Я утверждаю, что первым шагом должно быть изъятие всех возможных документов у заказчика и их анализ. Предметное интервью — это уже второй шаг. Твоё мнение — никаких бумаг рассматривать не надо, нужно сразу брать быка за рога и вытряхивать из него всю возможную информацию. Я прав?

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

IT>Стоп. Сейчас ты меня уташишь во флейм модель данных vs потоки управления.
IT>Давай ка step back.
IT>Мы здесь обсуждаем начало общения с заказчиком, первое интервью. Так? Вот давай это и обсуждать. Я утверждаю, что первым шагом должно быть изъятие всех возможных документов у заказчика и их анализ. Предметное интервью — это уже второй шаг. Твоё мнение — никаких бумаг рассматривать не надо, нужно сразу брать быка за рога и вытряхивать из него всю возможную информацию. Я прав?

Я предпочитаю начать с интервью, в нем определить ключевые виды деятельности, основных участников. Получив общее представление, провести интервью с руководителями подразделений и конкретными исполнителями на предмет, "ваша повседневная работа". Лучше к этому моменту иметь копии всех документов (образцы подготавливаются этими отделами), для того, чтобы в процессе интервью сразу "прикреплять" все бумажки к соответсвующим пунктам. В этот же момент основные вопросы связанные с формированием этих документов. После того, как все бумажки будут приколоты на свои места, начинаю их изучать более внимательно.
Начинать с анализа первички считаю неправильным по след. причинам:
1 если заказчик пропустит несколько важных образцов, это может не всплыть достаточно долгое время — ты обратишься за разъяснениями по собранным документам и получишь их. Чтобы выйти на пропущенные документы придется переключиться на вопросы типа "а чем вы еще занимаетесь" и "не забыли-ли вы чего"? Т.е. вернуться с обсуждению в стиле "расскажите о своей повседневной работе". Поэтому я начинаю с него.
2 кроме названий документов вряд-ли удастся выявить что-то существенное. Если я неправ, поясни этот момент.
3 начав с самостоятельного анализа первички можно сделать ложные предположения о структуре бизнеса, при интервьюировании опасность этого существенно ниже.

Опиши более конкретно преимущества, которые дает тебе твой подход, если получится, на простом примере. Укажи недостатки, которые дискредитируют мой подход.

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

IT>>Мы здесь обсуждаем начало общения с заказчиком, первое интервью. Так? Вот давай это и обсуждать. Я утверждаю, что первым шагом должно быть изъятие всех возможных документов у заказчика и их анализ. Предметное интервью — это уже второй шаг. Твоё мнение — никаких бумаг рассматривать не надо, нужно сразу брать быка за рога и вытряхивать из него всю возможную информацию. Я прав?

g_i>Я предпочитаю начать с интервью, в нем определить ключевые виды деятельности, основных участников. Получив общее представление, провести интервью с руководителями подразделений и конкретными исполнителями на предмет, "ваша повседневная работа". Лучше к этому моменту иметь копии всех документов (образцы подготавливаются этими отделами), для того, чтобы в процессе интервью сразу "прикреплять" все бумажки к соответсвующим пунктам. В этот же момент основные вопросы связанные с формированием этих документов. После того, как все бумажки будут приколоты на свои места, начинаю их изучать более внимательно.

Это не начало, это план работ минимум на неделю

g_i>Начинать с анализа первички считаю неправильным по след. причинам:
g_i>1 если заказчик пропустит несколько важных образцов, это может не всплыть достаточно долгое время — ты обратишься за разъяснениями по собранным документам и получишь их. Чтобы выйти на пропущенные документы придется переключиться на вопросы типа "а чем вы еще занимаетесь" и "не забыли-ли вы чего"? Т.е. вернуться с обсуждению в стиле "расскажите о своей повседневной работе". Поэтому я начинаю с него.

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

g_i>2 кроме названий документов вряд-ли удастся выявить что-то существенное. Если я неправ, поясни этот момент.

Дай мне пример конкретного документа и я тебе всё поясню

g_i>3 начав с самостоятельного анализа первички можно сделать ложные предположения о структуре бизнеса, при интервьюировании опасность этого существенно ниже.

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

g_i>Опиши более конкретно преимущества, которые дает тебе твой подход, если получится, на простом примере. Укажи недостатки, которые дискредитируют мой подход.

Твой подход — это стандартный путь, в принципе большинство делает именно так. Но это вовсе не значит, что этот путь самый оптимальный. Анализ документов — это другой путь начать общение с заказчиком, т.к. во время анализа ты уже можешь оценить разнообразие информации, ознакомится с терминологией, увидеть специфику, особенно если ты уже раньше занимался чем-то подобным. Дальше ты уже идёшь к заказчику и задаёшь вполне конкретные понятные ему вопросы, а не что-то абстрактное "Ну и что мы тут собираемся автоматизироавть". Привести пример я могу, если ты мне дашь какой-нибудь бланк или отчёт. Выдумывать что-то из головы мне лень, а текущая предметная область в которой я сейчас работаю, боюсь будет слишком далека от российской действительности

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

IT>Здравствуйте, g_i, Вы писали:
IT>Твой подход — это стандартный путь, в принципе большинство делает именно так. Но это вовсе не значит, что этот путь самый оптимальный. Анализ документов — это другой путь начать общение с заказчиком, т.к. во время анализа ты уже можешь оценить разнообразие информации, ознакомится с терминологией, увидеть специфику, особенно если ты уже раньше занимался чем-то подобным. Дальше ты уже идёшь к заказчику и задаёшь вполне конкретные понятные ему вопросы, а не что-то абстрактное "Ну и что мы тут собираемся автоматизироавть". Привести пример я могу, если ты мне дашь какой-нибудь бланк или отчёт. Выдумывать что-то из головы мне лень, а текущая предметная область в которой я сейчас работаю, боюсь будет слишком далека от российской действительности

Лады, я тебя понял.

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

g_i>>Ты предпочитаешь начинать с модели данных — я с набросков потоков упреавления.

IT>Потоков управления чем? Не данными ли?

Это называется ERD vs DFD. То есть по причинам не имеющим видимых оснований в объективной реальности разные люди предпочитаю начинать либо со схемы данных, либо c потоков. Не лечится. Да и что лечить-то?

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

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

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


Есть прекрасная книга "Принципы работы с требованиями к программному обеспечению. Унифицированный подход" Леффингуэлл, Уидриг. Она позволит понять, как общаться с заказчиками, исследуя область автоматизации. Книга легко адаптируется под конкретные нужды. Я ей в свое время поставил оценку "Обязательно для чтения"

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

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

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

Б>А с остальным согласен!!! Пока остановились на дополнительном Допросе!
Работая над одной системой, мы научили заказчика читать диаграммы IDEFx, каковые в данном случае были наиболее просты для понимания, и путем спуска сверху вниз по диаграммам, довольно быстро выяснили потоки информации в компании и ответственных людей. Использовали для этого BPWin и было это в 2000 году...

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

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

g_i>>Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.

IT>Буду начинать строить модель данных.

Не актуально. Это устаревший подход, который проигрывает по эффективности подходу со стороны бизнес-модели. Строить-то всё равно приходится и модель данных, и бизнес-модель, но только быстрее это делать не с модели данных.

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

g_i>>>Ок. Тебе вывалили ворох бумаг — образцов форм отчетности и певичных документов. Что ты со всем этим будешь делать? Как будешь анализировать? Имеется в виду, предварительных сведений об организации у тебя нет. Нет ТЗ, нет сформулированных требований к системе.

IT>>Буду начинать строить модель данных.

OS>Не актуально. Это устаревший подход, который проигрывает по эффективности подходу со стороны бизнес-модели. Строить-то всё равно приходится и модель данных, и бизнес-модель, но только быстрее это делать не с модели данных.

А с чего?

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

A>Работая над одной системой, мы научили заказчика читать диаграммы IDEFx, каковые в данном случае были наиболее просты для понимания, и путем спуска сверху вниз по диаграммам, довольно быстро выяснили потоки информации в компании и ответственных людей. Использовали для этого BPWin и было это в 2000 году...

Тут уже Влад писал про проверенные средства... Но были ли вы достаточно осторожны, дабы злые языки не обвинили вас в чёрствости?