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

Тестирование бизнес-модели процессов на предприятии

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

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

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

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

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

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

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