Автоматизация подготовки производства на предприятии:

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

Ключевые моменты

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

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

Этапы внедрения ИСУ

Бизнес-модель — это осязаемый результат, с помощью которого можно максимально конкретизировать цели внедрения ИСУ предприятия и определиться со следующими параметрами проекта:
1) перечень участков внедрения и последовательность их автоматизации;
2) фактическая потребность в объемах закупаемого программного и аппаратного обеспечения;
3) реальные оценки сроков развертывания и запуска ИСУ;
4) уточненный список членов команды внедрения и ключевых пользователей;
5) степень соответствия выбранного вами прикладного ПО специфике бизнеса вашей компании и многое другое.

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

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

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

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

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

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

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

На самом деле в основе бизнес-модели всегда лежат бизнес-цели предприятия, по большому счету полностью определяющие состав всех базовых компонентов бизнес-модели:
- бизнес-функции, описывающие, ЧТО делает бизнес;
- бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;
- организационная структура, определяющая, ГДЕ исполняются бизнес-функции и бизнес-процессы;
- фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;
- роли, определяющие, КТО исполняет бизнес-процессы;
- правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.

Схема бизнес-процессов

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

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

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

Две бизнес-модели: исходная «как есть» и целевая «как будет»

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

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

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

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

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

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