Этапы консалтингового процесса. Консалтинговый проект

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

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

Оценка и отбор альтернативных решений.

Консультант должен обеспечивать объективную основу для выбора, который осуществляется из двух и более решений (консультант должен доказать, что новое решение лучше существующего).

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

Представление предложений клиенту.

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

Но при этом консультант  должен объяснить:

• возможный риск (подобные решения никогда раньше не применялись реальные затраты могут быть выше, чем предполагалось, и т.п.);
• условия, которые клиент должен создать для реализации предложенных решений (финансовые и трудовые затраты, изменения кадрового состава и т.д.).

Решение, принятое по предложению  консультанта, может быть конечным этапом проекта, если клиенту не потребуется  дальнейшая помощь консультанта.

Этап 3: внедрение решений.

Консультант может принимать участие в реализации своих предложений:

• обеспечивая советами персонал, ответственный за реализацию;
• корректируя некоторые детали выработанных ранее решений;
• обучая персонал клиента.

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

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

Обучение новым методам  работы предполагает проведение семинаров, дискуссий, создание специальных проектных групп и т.п.

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

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

 

1.3 Послепроектная стадия

 

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

 

2. Консалтинговый проект

 

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

Основными целями разработки консалтинговых проектов являются:

• представление деятельности предприятия и принятых в нем технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения;
• формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;
• упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;
• выработка рекомендаций по построению рациональных технологий работы подразделений предприятия и его взаимодействию с внешним миром;
• анализ требований и проектирование спецификаций корпоративных информационных систем;
• рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями (прежде всего классов MRP - manufacturing resource planning и ERP - enterprise resource planning).

Структура подхода к  разработке консалтинговых проектов приведена  на рис.1. Опишем перечисленные этапы  более подробно:

1. Анализ первичных  требований и планирование работ

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

2. Проведение обследования  деятельности предприятия

В рамках данного этапа  осуществляется:

• предварительное выявление требований, предъявляемых к будущей системе;
• определение оргштатной и топологической структур предприятия;
• определение перечня целевых задач (функций) предприятия;
• анализ распределения функций по подразделениям и сотрудникам;
• определение перечня применяемых на предприятии средств автоматизации.

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

 

Рис.1. Структура подхода

 

В качестве исходной информации при  проведении обследования и выполнении дальнейших этапов служат:

• данные по оргштатной структуре предприятия;
• информация о принятых технологиях деятельности;
• стратегические цели и перспективы развития;
• результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);
• предложения сотрудников по усовершенствованию бизнес-процессов предприятия;
• нормативно-справочная документация;
• опыт системных аналитиков в части наличия типовых решений.

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

3. Построение моделей  деятельности предприятия

На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

• модели “как есть”, представляющей собой "снимок" положения дел на предприятии (оргштатная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнес-процессы и т.д.) на момент обследования и позволяющей понять, что делает и как функционирует данное предприятие с позиций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации;
• модели “как должно быть”, интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия.

Каждая из моделей  включает в себя полную структурную функциональную модель деятельности (например, в виде иерархии диаграмм потоков данных с разработанными для всех процессов нижнего уровня подробными их спецификациями на структурированном естественном языке или в виде иерархии SADT-диаграмм), информационную модель (как правило, с использованием нотации “сущность-связь”), а также, в случае необходимости, событийную (описывающую поведение) модель (с использованием диаграмм переходов состояний).

Переход от модели “как есть” к модели ”как должно быть” осуществляется следующими двумя способами.

• Совершенствование технологий на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников (“легкий” реинжиниринг).
• Радикальное изменение технологий и переосмысление бизнес-процессов (“жесткий” реинжиниринг). Например, вместо попыток улучшения бизнес-процесса проверки кредитоспособности клиента, может быть следует задуматься, а нужна ли вообще такая проверка? Возможно затраты на такие проверки каждого из клиентов во много раз превышают убытки, которые может понести компания в отдельных случаях недобросовестности (в случае, когда клиентов много, а суммы закупок незначительны)

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

• Модель “как есть” включает в себя существующие неавтоматизированные технологии, работающие на предприятии. Формальный анализ этой модели позволит выявить узкие места в технологиях и предложить рекомендации по ее улучшению (независимо от того, предполагается на данном этапе автоматизация предприятия или нет).
• Она позволяет осуществлять автоматизированное и быстрое обучение новых работников конкретному направлению деятельности предприятия (так как ее технология содержится в модели) с использованием диаграмм (известно, что "одна картинка стоит тысячи слов").
• С ее помощью можно осуществлять предварительное моделирование нового направления деятельности с целью выявления новых потоков данных, взаимодействующих подсистем и бизнес-процессов.

4. Разработка системного  проекта

Данный этап является первой фазой разработки собственно системы автоматизации (именно, фазой  анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.

На этом этапе определяются:

• архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;
• интерфейсы и распределение функций между человеком и системой;
• требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;
• состав людей и работ, имеющих отношение к системе;
• ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).

Системный проект строится на основе модели “как должно быть”  и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (например, IDEF0 или IDEF3), информационную модель, например, в соответствии со стандартом IDEF1X, а также техническое задание на создание автоматизированной системы (например, в соответствии с ГОСТ 34.602-89).

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

Необходимо отметить следующее достоинство системного проекта. Для традиционной разработки характерно осуществление начальных  этапов кустарными неформализованными способами. В результате заказчики и пользователи впервые могут увидеть систему после того, как она уже в большей степени реализована. Естественно, эта система отличается от того, что они ожидали увидеть. Поэтому далее следует еще несколько итераций ее разработки или модификации, что требует дополнительных (и значительных) затрат денег и времени. Ключ к решению этой проблемы и дает системный проект, позволяющий: