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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

Резюме