Консалтинговый проект, его создание и внедрение

СОДЕРЖАНИЕ 

ВВЕДЕНИЕ………………………………………………………………………..2

1. Цели и этапы разработки консалтинговых проектов…………..………..4
2. Анализ первичных требований и планирование работ. Проведение обследования деятельности предприятия……………………………...…5
3. Построение моделей деятельности предприятия. Разработка системного проекта…………………………………………………...……7
4. Разработка предложений по автоматизации предприятия. Последующие этапы………………...……………………………………11

ЗАКЛЮЧЕНИЕ……………………………………………………………….…13

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ……………………………14 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

ВВЕДЕНИЕ 

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

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

    Фактически  консультантом выполняется два  вида работ. Прежде всего это элементарное наведение порядка в организации: бизнес-анализ и реструктуризация (реинжиниринг бизнес-процессов). Это направление  получило название “бизнес-консалтинг”.

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

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

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

1. Цели  и этапы разработки консалтинговых проектов

 

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

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

    - формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;

    - упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

    - выработка рекомендаций по построению рациональных технологий работы подразделений предприятия и его взаимодействию с внешним миром;

    - анализ требований и проектирование спецификаций корпоративных информационных систем;

    - рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями (прежде всего классов MRP - manufacturing resource planning и ERP - enterprise resource planning).

    Структура подхода к разработке консалтинговых проектов приведена на рис. 1. [3, c. 44]

    

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

2. Анализ первичных требований и планирование работ. Проведение обследования деятельности предприятия

 

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

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

    - предварительное выявление требований, предъявляемых к будущей системе;

    - определение оргштатной и топологической структур предприятия;

    - определение перечня целевых задач (функций) предприятия;

    - анализ распределения функций по подразделениям и сотрудникам;

    - определение перечня применяемых на предприятии средств автоматизации.

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

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

    - данные по оргштатной структуре предприятия;

    - информация о принятых технологиях деятельности;

    - стратегические цели и перспективы развития;

    - результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);

    - предложения сотрудников по усовершенствованию бизнес-процессов предприятия;

    - нормативно-справочная документация;

    - опыт системных аналитиков в части наличия типовых решений.

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

3. Построение  моделей деятельности предприятия. Разработка системного проекта

 

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

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

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

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

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

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

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

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

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

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

    - архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;

    - интерфейсы и распределение функций между человеком и системой;

    - требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;

    - состав людей и работ, имеющих отношение к системе;

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

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

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

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