Сергей Бобровский

 

В статье “Моделирование бизнеса” (см. PC Week/RE, № 16, с. 44), продолжающей разговор об управлении бизнесом, авторы упоминают о метамоделях для бизнесов одного типа (назовем их метамоделями бизнеса, ММБ), которые могут быть использованы “в качестве заготовок и позволяют переносить накопленный управленческий опыт из одного рода деятельности в другой”. В идеале разговор о моделировании бизнеса и надо было начинать с рассмотрения таких метамоделей, а не моделей (МБ), пусть даже стратегического уровня, потому что отсутствие в компании продуманной организационной политики и, самое главное, методов, обеспечивающих ее выполнение, нельзя компенсировать внедрением моделей более низкого уровня. Как известно, успешно (с разумными отклонениями от сроков и бюджета) заканчивается только 30% крупных проектов по автоматизации предприятий. Нередко бывает, что аналитики строят модели “как есть” и “как должно быть”, вырабатывают рекомендации по реинжинирингу бизнес-процессов, программисты создают и настраивают КИС, другие специалисты ее внедряют, учат персонал, а спустя некоторое время выясняется, что никакого эффекта КИС не принесла, а издержки в компании возросли. Дело в том, что с КИС надо уметь работать, и надо уметь правильно организовать эту работу. Функциональные модели, должностные инструкции, схемы документооборота - это все статические, мертвые атрибуты МБ. А вот помощи в решении вопросов, какие действия надо предпринять руководству, чтобы модель работала, инструкции исполнялись, а КИС действительно влилась в цикл адаптивного управления - а подобных действий сотни! - обычно не предлагается. В лучшем случае предлагаются услуги консультанта (100 и более долларов в час), который будет более или менее регулярно наведываться к клиенту, помогая решать тактические проблемы.

Некоторые эксперты считают, что способность правильно организовать работу с помощью КИС зависит только от опыта. Но это неверно: на Западе соответствующие ММБ созданы, причем довольно давно, и руководствоваться заложенными в них формальными правилами, не привлекая дорогостоящих бизнес-консультантов - просто прослушав, например, разовые курсы, способен любой руководитель. В числе последних появились ММБ для фирм-разработчиков и фирм - потребителей ПО (как уже говорилось, потреблять КИС тоже надо уметь, и это подчас не проще, чем ее разработать). Подобные ММБ продуманы очень четко и постоянно совершенствуются.

В чем отличие ММБ от МБ? ММБ не имеют локальных целей. Они предназначены только для непрерывного (и неограниченного!) повышения производительности труда и качества продукта. МБ же, напротив, ориентированы на локальные цели (авторы упомянутой статьи определяют модель объекта как нечто, способное отвечать на вопросы по поводу этого объекта). Различные модели помогают ответить на разные вопросы. Модель финансового управления - как движутся финансовые средства в организации? кто виноват, что пропало пять миллионов? как найти виновного? Маркетинговая модель - как влияет внешняя среда на конкретный бизнес? Модель управления производством - как протекает процесс управления? и (возможно) как его улучшить? Модель управления логистикой - как организованы процессы снабжения? И т. д. С помощью средств прогнозирования “что, если...” можно дополнительно получить ответы на вопросы типа “как изменятся такие-то показатели деятельности, если...”. Обратите внимание: все подобные вопросы начинаются с местоимения “как”, то есть они “задаются” по классической модели “как должно быть”. Однако подобные модели, в отличие от ММБ, в принципе не способны ответить на вопросы - что делать, чтобы не дать пропасть пяти миллионам? что делать, чтобы процессы управления улучшались?” (но не как конкретно их улучшить! - конкретных рекомендаций ММБ никогда не предлагают). Среди ответов ММБ на последний вопрос может быть такой - воспользоваться услугами бизнес-консультантов. Для этого требуется выполнить формально определенную ММБ бизнес-процедуру с учетом множества оговорок и дополнительных требований. Кстати, в цикле статей несколько странно смотрятся призывы “давайте договоримся о терминологии”, когда эта терминология уже давно разработана и успешно применяется во всем мире. Например, стандарт IEEE STD-610 определяет понятие “процедура” следующим образом: письменное описание хода действий, предпринимаемых для достижения заданной цели. Определены в IEEE и такие понятия, как “модель”, “процесс”, “задача”, “цель”, “действие”, “практика” и т. д.

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

Метамоделей бизнеса “для общего пользования” насчитывается с десяток (имеются и внутрикорпоративные ММБ), и они охватывают все области от создания КИС до организации работ с персоналом компании-разработчика и процесса внедрения КИС у заказчика. Конечно, максимальный эффект эти метамодели дают при их комплексном использовании (для чего созданы специальные мета-ММБ!). То есть при внедрении КИС должна быть обязательно формализована организационная политика, охватывающая все уровни деятельности предприятия сверху донизу (многие из этих уровней, например психологический климат в коллективе, можно описать только качественно), чтобы заработала модель “как должно быть”, которая на своем уровне обычно не допускает элементов нечеткости - а ведь нечеткость всегда присутствует в работе любого предприятия, особенно российского.

К автору можно обратиться по адресу: sbo@pcweek.ru.