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

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

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

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

Дмитрий Геннадьевич Слиньков — директор по внедрению компании «БААН Евразия». Ему можно написать по адресу: Dslinkov@baan.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ошибочно полагать, что бизнес-модель — это просто комплект документов, описывающий только бизнес-процессы предприятия. На самом деле в основе бизнес-модели всегда лежат бизнес-цели предприятия, по большому счету полностью определяющие состав всех базовых компонентов бизнес-модели [2] (см. рис. 2):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Тестирование проектной группой. Как уже было сказано, желательно совместить эту стадию с первой, устранив тем самым лишнее ресурсоемкое звено в цепочке приемки модели. Данная стадия выделяется только тогда, когда условия реализации проекта внедрения ИСУ на предприятии выражаются в простом, понятном, но неосуществимом словосочетании «под ключ».

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

• Специально для целей тестирования выделяется рабочее помещение, где установлено несколько компьютеров, подключенных к ИСУ, сконфигурированной в соответствии с текущей версией бизнес-модели. Группа ключевых пользователей самостоятельно имитирует работу своего предприятия по специально разработанному сценарию теста. Организационная структура моделируемого предприятия должна быть разумно упрощена, иначе каждому ключевому пользователю придется слишком часто подключаться к системе от имени сотен рядовых пользователей.
• Группа внешних консультантов при этом не должна вмешиваться в процесс тестирования. Приглашенные на данный процесс руководители предприятия, напротив, должны принимать самое активное участие, задавая каверзные вопросы своим подчиненным на предмет того, как в системе будет осуществляться та или иная специфическая операция. При таком подходе ключевые пользователи получают возможность дополнительно «набить руку», а руководители — получить более глубокие знания о системе. (Довольно часто тестирование ИСУ становится очень полезной во многих отношениях деловой игрой. Руководители, получая неизвестные им до сего момента сведения, узнают много нового о своих предприятиях, происходят столкновения интересов, выявляются противники внедрения и т. д. Но это уже совсем другая тема, заслуживающая отдельного обсуждения.)
• Группа внешних консультантов, в зависимости от успешности сдачи ключевыми пользователями бизнес-модели своему руководству, получает оценку собственной работы.

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

• Основным критерием правильности построения целевой бизнес-модели является сбалансированность целей и средств. Если внедрение модулей интеллектуального планирования производственных ресурсов (например, MRP II) приведет к тому, что раз в сутки на вашем предприятии придется останавливать сборочный конвейер на несколько часов, чтобы получить результаты автоматического распределения производственных заказов, то, очевидно, что-то неправильно в бизнес-модели. При статическом (или «бумажном») рассмотрении модели такое несоответствие разглядеть невозможно.
• Не бойтесь многократно повторять процесс тестирования, выявления недостатков, доработки модели и вновь тестирования. В мире нет консультантов или разработчиков, способных построить для вас ИСУ, что называется, с ходу. Лучше с опаской относиться к тем, кто утверждает, что сможет без необходимости дальнейших доработок запустить ИСУ на вашем предприятии в считанные недели.

Чтобы помнили

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

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

Необходимо помнить, что в силу творческого характера самого процесса моделирования проект очень легко может выйти за собственные рамки, поэтому желательно применять некоторые специфические приемы управления таким проектом, например, технологию контроля итеративных процессов разработки информационной системы — таймбоксинг (Timeboxing — «временной квадрат», см. [1]). Но подробное рассмотрение этого вопроса выходит за рамки данной статьи.

Литература

Резюме