Информационные технологии управления / УМК

321

создание руководства пользователя;

обучение.

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

Этап 4:

подготовка данных;

перенос, конвертация, загрузка данных в систему Scala;

проверка результатов (например, входящее сальдо и аналитика). Этап 5:

тестовое испытание системы. Этап 6:

сдача проекта;

аудит системы;

проверка подготовленной в рамках проекта документации;

передача проекта группе ключевых пользователей.

Заключение: ―Наша главная задача – совместно с клиентом, используя методологию внедрения Signature, достичь поставленной цели в срок и в пределах запланированного бюджета‖.

Сильные стороны приведенного плана:

много внимания уделяется эффективной организации проекта, взаимодействию заказчика и исполнителя;

подробно расписан этап предварительного обследования;

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

не упомянуты Техническое задание и Технический проект;

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

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

1С-Рарус

Задача фирмы – ―разработка и внедрение продуктов 1С и оригинальных конфигураций, созданных на платформе 1С‖.

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

Методика предусматривает следующие этапы: предварительное обследование;

составление перечня работ и план-графика его исполнения;

конфигурирование;

тестирование и ввод в эксплуатацию;

сопровождение.

В первом пункте приводится сравнительно подробное описание стандартного предпроектного обследования.

Второй раскрывается следующим образом: ―По построенной ранее на этапе предварительного обследования модели автоматизации подготавливается подробный перечень работ. Каждый его пункт детально обсуждается и согласовывается с заказчиком. План-график отражает согласованные сроки выполнения каждого пункта перечня работ‖.

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

322

Конфигурирование: ―Основной по продолжительности этап внедрения, на котором производится модификация ―1С:Предприятия‖ в соответствии с разработанным и согласованными ранее перечнем работ в сроки, определенные в плане-графике. Может быть разбит на несколько промежуточных, каждый из которых контролируется, тестируется и сдается отдельно‖.

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

Не осмелимся усомниться, что ―уникальная‖ методика 1С-Рарус обеспечивает успешность многочисленных внедрений фирмы, однако часть ее, представленная на сайте, не слишком впечатляет.

Компания является весьма ―раскрученной‖ в своей ценовой нише. Она одной из первых (если не первой) создала на платформе 1С модуль ―Производство‖ (цена за одно рабочее место – более 500 долларов).

Услуги специалистов 1С-Рарус не дешевы. По собственному опыту: работа постановщика и программиста по доработке упомянутого модуля была оценена в 10 000 долларов за два месяца. Правда, за эту сумму нам обещали действительно классных профессионалов.

Вкомпании проводятся семинары по MRP и MRPII и сертификация специалистов в этой области.

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

Обучение предусмотрено лишь на этапе тестирования, управление данными вообще не упоминается. Такая методика может работать только на очень маленьких проектах, да и то с оговорками.

При этом именно 1С-Рарус особо акцентировала внимание на вопросах качества, отметив что контроль качества ведется на протяжении всего проекта. В компании существует специальное подразделение, которое занимается этой проблемой. Фирма планирует получить сертификат ISO 9001.

ЭпикРус

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

Согласно концепции фирмы, полномасштабное внедрение включает:

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

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

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

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

фазу перехода на новую систему (поддержка пользователей, ―тонкая‖ настройка системы, дополнительные работы, обзор состояния после перехода, результаты внедрения продуктов).

323

Трудно сказать, готов ли потенциальный заказчик (не специалист) ―переварить‖ столь широкий объем информации. Однако имидж серьезной и основательной организации, бесспорно, создать удалось.

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

Недостатки: не выделены в особые этапы Обработка данных и создание ТЭО; не всегда определяются выходные документы этапов (ТЗ, ТП).

Некоторое недоумение вызвала информация о том, что предпроектное обследование формализуется в нотации SADT. По статистике SADT используют для описания бизнес-процессов в 10% случаев, а в 90% – DFD. Это связано с тем, что SADT изначально создавали для описания производственных процессов, а не моделей информационных систем.

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

4.4.3. Управление проектами при создании информационных систем

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

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

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

сформировать рабочую (проектную) группу в центральном офисе и на местах (филиалах) со следующими задачами:

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

руководит и контролирует процесс в целом:

o готовит вопросы на утверждение управляющего комитета; o осуществляет интерфейс с поставщиком.

Минимальное количество сотрудников отдела АСУ для поддержания работоспособности системы ―класса предприятия‖ (при односменной работе) - 5-6

324

человек, из них должен быть как минимум 1 - специалист - системотехник (то есть специалист по взаимодействию прикладных задач и операционно-управляющих систем), 1 - специалист по поддержке Базы Данных и программированию. Остальные - специалисты по прикладным подсистемам, сюда не входят специалисты по поддержанию работоспособности локальной вычислительной сети и технических средств связи. Также не учтен персонал, необходимый для ввода данных при ―неполном охвате‖ или ―неполной интеграции‖ системы, что часто встречается при отечественной любви к ―экономии‖. Естественно, в каждом подразделении, должны быть выделены и подготовлены ―квалифицированные пользователи‖ обеспечивающие

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

сформировать корпоративные стандарты:

финансового учета;

план счетов;

учетная политика;

шифры аналитического учета;

материального учета;

справочник-кодификатор материалов;

стандарты учета товародвижения;

финансовые документы;

учетные регистры;

сопроводительные документы;

принципы управления складскими запасами в разрезе материалов;

производственного учета;

принципы расчета себестоимости;

принципы отнесения затрат;

принципы учета вспомогательных и побочных производств; Уровень детализации корпоративных стандартов зависит от уровня интеграции

бизнес- и финансовых процессов головной организации и подразделений. Наиболее простой вариант - чистый холдинг, то есть ситуация независимо хозяйствующих субьектов, итоги работы которых, как правило, консолидируются и оцениваются раз в год на уровне некоторого итогового (специального) плана балансовых счетов. Данный вариант пока редко используется в отечественной практике, так как отсутствует распространенная (принятая) методика консолидации учета, которая обеспечивала бы исключение внутрихолдинговых оборотов. Хотя в принципе российская практика учета уже позволяет использовать первый вариант - консолидацию практически стандартным (принятым на Западе) образом. Наиболее сложный вариант - ―распределенное‖ предприятие, состоящее из нескольких территориально существенно удаленных филиалов, ведущих сложную хозяйственную деятельность, например производственных. Последний вариант особенно усложняется типично российской проблемой отсутствия хороших скоростных каналов связи.

начать процесс Крайне редко (точнее - практически никогда) удается обойтись в данном

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

325

предположений ―по умолчанию‖, вообще говоря, неверных в Российской практике, а именно:

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

изатратам. ( При этом существует или создается в ходе проекта адекватное письменное описание поставленных целей).

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

3.Руководство и специалисты заказчика умеют применять или, по крайней мере, имеют представление о стандартных технологиях управления бизнесом, таких как, SIC, MRP, Supply Chain, TQM, ISO9000 и пр., и не требуется специальное обучение в случаях использования их элементов в проекте (по крайней мере, в части технологий, уже используемых заказчиком).

4.Работает иерархическая структура управления - то есть распоряжения руководства безусловно обязательны для исполнителей.

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

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

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

4.4.4. Бизнес-моделирование для внедрения ИСУ предприятия

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

Мастерство — это когда «что» и «как» приходят одновременно

В. Э. Мейерхольд

Ключевые моменты Нужна ли вам модель «как есть»?

Как не увлечься моделированием ради моделирования

Практика интеграции систем моделирования с системами автоматизации

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

Реинжиниринг или оптимизация?

Любой проект внедрения ИСУ (интегрированной системы управления) предприятия состоит из двух этапов:

a.разработка прототипа будущей системы (называемого также «бизнесмоделью», «проектным решением» и т. п.);

b.развертывание системы или ее части (см. рис. 4.4.1).

326

Рис. 4.4.1. Развертывание системы

Поэтому, чтобы получить оптимальное решение, способное принести практическую пользу и вместе с тем приемлемое по стоимости, лучше не рассматривать проект внедрения ИСУ как единый контракт – от обследования до ввода в промышленную эксплуатацию интегрированной системы по всем участкам предприятия. Начните с малого: заключите контракт с поставщиком прикладного пакета для построения ИСУ или с консалтинговой фирмой исключительно на стадию бизнес-моделирования. Ни в коем случае не ограничивайтесь «только обследованием» и прочими не целостными способами решения ваших проблем. Бизнес-модель – это осязаемый результат, с помощью которого можно максимально конкретизировать цели внедрения ИСУ предприятия и определиться со следующими параметрами проекта:

1.перечень участков внедрения и последовательность их автоматизации;

2.фактическая потребность в объемах закупаемого программного и аппаратного обеспечения;

3.реальные оценки сроков развертывания и запуска ИСУ;

4.уточненный список членов команды внедрения и ключевых пользователей;

5.степень соответствия выбранного вами прикладного ПО специфике бизнеса вашей компании и многое другое.

Конечно, создание бизнес-модели – процесс не быстрый и занимает обычно от четырех до девяти месяцев. Главное – набраться терпения и получить ответы на давно назревшие вопросы. Естественно, если речь идет о локальной автоматизации бухгалтерского учета, то результата можно добиться быстрее. Однако при комплексной широкомасштабной автоматизации ошибки в планировании стоят больших денег.

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

Один рисунок стоит тысячи печатных слов

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

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

327

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

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

визуализировать деятельность предприятия, обеспечив руководству возможность правильно оценить имеющиеся недостатки и отыскать источники потенциала и направления усовершенствования;

сократить время настройки ИСУ под специфические особенности предприятия;

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

Иными словами, бизнес-модель является отображением предприятия и его информационно-управляющей системы. Без бизнес-модели вы не сможете построить действительно интегрированную и «всеобъемлющую» ИСУ. Именно при создании бизнес-модели формируется «язык общения» консультантов, разработчиков, пользователей и руководителей предприятия, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприятия («корпоративная система управления»). Очень важно с самого начала определиться, на кого вы будете ориентироваться при построении модели, то есть кто будет ее конечным потребителем. В большинстве случаев ответ на этот вопрос один: руководство компании. Все попытки использования точек зрения главного бухгалтера или коммерческого директора превращают модель промышленного предприятия в модель финансового института.

Рисуйте, как только можете!

С особой тщательностью следует подходить к формату представления бизнес-

модели. Популярная методология SADT (Structured Analysis and Design Technique) или рожденная на ее основе IDEF0 действительно хороши там, где практически отсутствуют описания функций и бизнес-процессов, а также в тех случаях, когда построением модели занимается не единая, слаженная команда, а, например, группа, состоящая из внешних консультантов, экспертов поставщика ИСУ и сотрудников самого предприятия. В таком случае можно гарантировать, что большинство членов «сборной» команды знакомы с общепринятым стандартом IDEF0 (в настоящее время его преподают во многих вузах), следовательно, можно сравнительно быстро приступить к работе над моделью, «поделив» между собой бизнес-функции предприятия.

Создаваемые диаграммы будут совместимы друг с другом и смогут впоследствии составить единую модель. Однако характерная для стандарта IDEF0 бедность изобразительных средств делает невозможным, например, описание сквозных бизнес-процессов, охватывающих весь цикл обработки заказа — от размещения до исполнения. Для подобных задач более подходящим инструментом могут служить такие известные системы проектирования, как ARIS («архитектор интегрированных информационных систем») или BAAN DEM («динамический моделировщик предприятий»). В общем, любой способ изображения модели хорош, если он нагляден и понятен руководству предприятия.

Не бизнес-процессом единым...

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

328

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

бизнес-функции, описывающие, ЧТО делает бизнес;

бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;

организационная структура, определяющая, ГДЕ исполняются бизнесфункции и бизнес-процессы;

фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;

роли, определяющие, КТО исполняет бизнес-процессы; правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.

Рис. 4.4.2. Сквозные бизнес-процессы

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

воздействия, инициирующие каждый шаг бизнес-процесса;

исполнители каждого шага (это могут быть как люди, так и программы и механизмы);

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

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

Кадры и здесь решают все

Моделирование ни в коем случае не должно стать внутренним процессом отдела ИТ. Так же верно и обратное: если ваше предприятие располагает внушительным бюджетом, позволяющим привлечь большую группу управленческих консультантов, то со стороны заказчика модели в совместную группу моделирования должны входить, помимо полностью выделенных для данного проекта ИТ-специалистов, менеджеры отделов и ключевые пользователи. Следует позаботиться о том, чтобы ВСЕ участники проектной группы к моменту начала работ по бизнес-моделированию прошли обучение методологии моделирования, основам проектирования больших систем, а также приобрели минимальные навыки работы с будущей ИСУ – познакомились с

329

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

В группе моделирования (внедрения) обязательно должна быть предусмотрена должность администратора бизнес-моделирования (АБМ). АБМ – это координатор усилий всей проектной группы по разработке модели. Ошибочно считать, что эту функцию должен выполнять «по совместительству» менеджер проекта. Его основная (и единственная) обязанность – управление проектом. АБМ же ведет оперативный аудит принимаемых в ходе внедрения решений, контролирует целостность базовой бизнесмодели и процесс ее корректировки, отслеживает оптимальность кодирования справочников и руководит процессом разработки интерфейсов внедряемой ИСУ с другими системами. Естественно, что АБМ подготавливает для менеджера проекта необходимую при принятии решений информацию. Если провести аналогию с государственным управлением, то АБМ – это власть законодательная, а менеджер проекта – власть исполнительная. На ранних стадиях проекта функцию АБМ может и должен (требуйте этого!) исполнять внешний консультант. Но с самого начала вам необходимо приставить к этому человеку специалиста-дублера «из своих», чтобы перенять опыт и полностью принять дела к началу опытной эксплуатации!

«Ничто не меняется так быстро, как прошлое»

При классическом подходе к внедрению новой ИСУ формируются две бизнесмодели: исходная («как есть») и целевая («как будет»). Описание исходной модели требуется для того, чтобы идентифицировать возможные недостатки в существующей системе управления предприятием. Выявление недостатков начинается еще на стадии описания модели «как есть». Дело в том, что в основу любого средства динамического моделирования закладывается та или иная методология структурирования больших массивов знаний об объекте. Любая методология такого рода подразумевает целый комплекс правил разной степени жесткости, несоблюдение которых делает задачу формализации получаемых знаний (то есть само построение модели) практически неосуществимой. Таким образом, невозможность формального целостного описания, например, бизнес-процесса оформления заказа выявляет проблему неоптимальности (излишней разветвленности, дублирования данных, слабого организационного описания и т. п.) самого бизнес-процесса. В местах подобного рассогласования правил и реалий каждый проектировщик вынужден отступать от методологических требований, тем самым визуально акцентируя внимание руководства предприятия на обнаруженных недостатках организации бизнеса.

Главный «подводный камень» моделирования исходной модели – время, которое мы затрачиваем на разработку. Чем динамичнее развивается ваше предприятие, тем меньше времени у вас остается на описание того, «как есть». Если, согласно вашим прикидкам, достоверность модели к моменту ее завершения составит не более 70%, возможно, имеет смысл описать только основные «сквозные» бизнеспроцессы, каждый из которых раскрывает последовательность шагов вашего предприятия на пути к извлечению прибыли от того или иного вида деятельности.

Рояль в кустах, или О пользе типовых моделей

Желательно, чтобы консультанты, которых вы привлекаете к проекту, обладали готовой отраслевой моделью. Такая модель-заготовка позволяет значительно сократить время на описание рутинных процессов, которые, каким бы уникальным вы свое предприятие ни считали, составляют львиную долю всех бизнес-процессов в компании. Не исключено, что и поучиться будет чему. Особенно если отраслевая модель представляет собой квинтэссенцию мирового опыта менеджмента в данной отрасли. Но не стоит питать иллюзий – это не «готовое к употреблению» предприятие, в котором как по мановению волшебной палочки сотрудники начинают работать с энтузиазмом,

330

менеджеры перестают делать ошибки, поставщики поставляют то, что заказано, а клиенты вовремя оплачивают счета. Если вспомнить перечень основных компонентов бизнес-модели, то там вы не найдете конкретных данных – справочника изделий, плана счетов, перечня складов и т.п. Ну и, по крайней мере, «готовая модель» обязательно нуждается в тестировании.

Бархатная революция

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

Моделирование ради моделирования

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

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

Попытка – не пытка, а путь к истине

Как правило, тестирование бизнес-модели проводится на четырех уровнях.

1. Внутреннее тестирование разработчика. В большинстве случаев рекомендуется объединяться с поставщиком даже на столь ранней стадии развития