2 Необходимо отметить специфические трудности постановки любой новой деятельности, связанные с тем, что сделав несколько шагов в правильном направлении и не получив мгновенной отдачи, компании зачастую прекращают проект, тем более, что регулярный менеджмент требует постоянных усилий не только при его внедрении, но и “всю оставшуюся жизнь”! Но это касается и любой внедряемой впервые техники управления, причем не только в России. См, например, цитату из предисловия авторов, Р. Манна, Э. Майера, к своей книге “Контроллинг для начинающих”:

В качестве концептуальной основы технологий бизнес-моделирования, БИГ-Мастер, ориентируется на два основополагающих принципа современного менеджмента, обозначенных в стандарте ИСО 9000:2000 как “процессный и системный подходы”:

• Желаемый результат достигается более эффективно, когда надлежащими ресурсами и видами деятельности руководят как процессами)
• Выявление, понимание и управление взаимосвязанными процессами как системой способствует результативности и эффективности организации при достижении ее целей.

Отсюда следует, что процессное описание – это не только выстроенные цепочки бизнес-операций, совершенствование которых безусловно улучшает логистику компании. Не менее важно понять и зафиксировать полную систему взаимосвязанных процессов компании, а также степень влияния каждого из них на достижение ее целей. Вот мнение Дейва Кокса, главного специалиста по информатике Northern Telecom: “Оказалось, что нам необходимо было выйти за пределы низкоуровнего моделирования процессов, которым сегодня занимаются многие фирмы. Это всего лишь тонкая регулировка существующей структуры. Мы поняли, что реорганизовывали бизнес-процессы, не располагая моделью предприятия в более широком смысле слова”

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

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

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

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

Для структурного анализа и проектирования процессов, описываемых потоковыми моделями БИГ:Мастер поддерживает методологию SADT (IDEF), которая в США является государственным стандартом, а в настоящее на ее базе подготовлен и аналогичный российский стандарт.

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

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

• Идентификатор и Наименование процесса
• Назначение и цели процесса
• Владелец процесса
• Участники процесса
• Предшествующий процесс (ы)
• Следующий процесс (ы)
• Преобразуемые ресурсы (на входе и выходе процесса)
• Нормативные документы, регулирующие процесс
• Документы или события инициирующие процесс
• Документы или записи порождаемые процессом

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

Уровни проекций позволяют отразить в отчете дополнительные свойства относящиеся к данному объекту (Например, для персонала, задействованного в процессе – квалификационные требования, а для продукции, полуфабрикатов и комплектующих изделий - технические).

Классификаторы, проекции и потоковые модели бизнес-процессов поддерживаются различными способами их отображения (визуализации). Для классификаторов - в виде списков и деревьев (орграфов), для проекции - в виде связанных списков и транспонируемых матриц (Рис.1), а для потоковых моделей бизнес-процессов (Рис. 2) в виде диаграмм IDEF0 (IDEF3) и текстового описания - что облегчает понимание задач участниками процессов!. (При этом конструирование самих потоковых моделей происходит в привычных табличных формах! – Рис. З)

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

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

Отметим, что наличие в БИГ:Мастере нескольких инструментов моделирования является чрезвычайно полезным. Матричные модели поддерживают “вертикальную интеграцию” - подробное системно–целевое описание компании, выстроенное по иерархии управления и исполняемым функциям. В чисто процессной потоковой модели преобладает функционально-технологический подход - “горизонтальная интеграция” бизнес-операций по процедурам – т.е. по их последовательностям с необходимой точностью и полнотой связывающим материальные и информационные потоки.

По своей функциональности БИГ-Мастер не имеет прямых аналогов и поэтому позиционируется среди нескольких классов продуктов.

Прежде всего, это упомянутые в начале статьи средства моделирования, входящие в состав зарубежных комплексных систем управления предприятиями.. Основанные на отработанных методологиях внедрения продуктов класса ERP, они существенно облегчают формальное описание деятельности предприятия. Своей ориентацией на работу в составе корпоративной информационной системы БИГ-Мастер близок к этим системам. Однако, он не поставляется в их составе, а является самостоятельным модулем, интегрируемым тем или иным образом с другими программными средствами.

Конечно же это и специализированные CASE–средства анализа и моделирования информационных систем (такие продукты, как BPwin фирмы Platinum Technologies или Rational Rose фирмы Rational Software). Особое место в перечне такого рода продуктов, принадлежит пакету Aris Toolset компании IDS Prof. Scheer, занимающему сейчас видное место на мировом рынке.

Но задачи БИГ-Мастера не ограничиваются этапом моделирования при проектировании информационной системы, как у систем перечисленных выше, которые являются, в большей мере, инструментом разработчика и «уходят» с предприятия вместе с ним. Модели БИГ-Мастера «навсегда» остаются на предприятии, предоставляя его менеджерам возможность наблюдения точной и полной картины организации бизнеса. Следствием этого различия, является отсутствие в CASE-средствах генерации документов-регламентов, ориентированных на менеджеров компании. В то время, как в БИГ-Мастере это является одной из главных задач (Рис. 4)! Кроме того, пользовательский интерфейс и технология моделирования БИГ-Мастера рассчитаны на «среднего» российского менеджера, а не только на кандидатов наук сосредоточенных в IT-компаниях занимающихся системной интеграцией. В то же время, при его создании учтен существующий уровень менеджмента и «инженерное» прошлое большинства российских руководителей, что, как показывает опыт, помогает скорейшему освоению новых технологий управления.

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

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

Возможны два варианта взаимодействия БИГ-Мастера с такими системами. Первый это организация экспорта создаваемых в нем описаний бизнес–процессов в готовые системы Workflow с использованием стандартных протоколов обмена данными. Другой, это создание собственных механизмов управления бизнес-процессами, что и реализуется в новой версии продукта, ориентированного на Интранет-технологии.

В настоящее время Workflow рассматривается как ключевая технология интеграции, которая наводит мосты между бизнес-процессами и информацией, необходимой для их реализации, объединяет унаследованные приложения и программное обеспечение настольных систем в гибкую и хорошо адаптируемую распределенную инфраструктуру. Эта тенденция развития хорошо соотносится с концептуальными представлениями группы БИГ о приоритетах задач решаемых в процессе построения информационных систем предприятия.

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

Современным решением является интегрированная корпоративная система управления, построенная на основе полной бизнес-модели компании.

В концептуальной модели (Рис.5) интегрированной корпоративной информационной системы (КИС) можно выделить, три класса программных подсистем условно названные «организационная», «исполнительная» и «аналитическая».

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

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

• Стратегическая модель целеполагания (отвечает на вопросы зачем какова «миссия» компании, какие цели и стратегии необходимо реализовать)
• Организационно-функциональную модель, (отвечает на вопросы кто и что делает в компании и кто за что отвечает)
• Функционально - технологическая модель (отвечает на вопросы что и как реализуется в процессах компании)
• Процессно-ролевая модель, объединяющая две предыдущих (отвечает на вопросы по кто-что-как-кому )

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

• Модель структур данных (отвечает на вопросы в каком виде накапливается и представляется информация о самой компании и ее внешнем окружении).

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

Объединение указанной совокупности моделей образует полную бизнес-модель компании (Рис.2). Она обеспечивает необходимую полноту и точность описания, придавая необходимую прозрачность организации бизнеса. Постоянный мониторинг внешней и внутренней среды, с целью анализа существенных для компании изменений, позволяет своевременно вносить коррективы в бизнес-модель и производить актуализацию регламентов деятельности. Корректировка модели может осуществляться не только под действием уже свершившихся изменений, а на основании их стратегического прогноза, что позволяет реализовать управление организационным развитием. Это обеспечивает высокую конкурентоспособность таких саморазвивающихся компаний.

«Исполнительная» подсистема является основным инструментом поддержания текущей деятельности, т.е. с ее помощью менеджеры компании реализуют корпоративные регламенты управления в реальном времени и на реальных данных. В составе этой подсистемы могут использоваться большинство известных на российском рынке программных продуктов для поддержи хозяйственной деятельности фирм 1С, Парус, Комтех, М2 и др., а также новейшие программы обеспечивающие взаимодействие компании с внешней средой (например, CRM-системы, системы управления цепочками поставок – SCM (Supplies Chains Management) и т.п.)

«Аналитическая» часть поддерживает стратегический уровень управления компанией – позволяют анализировать, прогнозировать и контролировать обобщенные индикаторы эффективности ее деятельности. В нее входят различные программы специальных областей анализа (ИНЭК, ПроИнвест Консалтинг и др.), использующих базы данных «исполнительной» подсистемы.

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

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

Рассмотренный выше вариант интеграции проводит эту стратегию в крайнем варианте – для создания корпоративной системы первоначально достаточно orgware. Он выполняет роль интегрирующей надстройки над базами данных действующих на предприятии учетных систем, придавая содержащейся в них информации осмысленность, и приближая, насколько это возможно, управленческие решения, к технологиям и практике менеджмента принятым во всем мире. (Дополнительное использование системы Workflow в качестве «информационной магистрали» еще более усилит эффективность решения).

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

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

В мире наметилась любопытная тенденция - крупнейшие компании, которые предлагают интегрированные решения в бизнесе – BAAN, Platinum и т.д. – начинают терять свои конкурентные позиции, потому что, приходя на предприятие, они пытаются установить полный список вопросов и говорят, что на их внедрение необходимо 1,5-2 года. Бизнес же настолько динамичен, что предприятие не может выделить сотни тысяч долларов, чтобы ждать годы и иметь риск неудавшейся системы, а неудач внедрения западных систем, как свидетельствуют факты, на российском рынке очень много. Уровень многих «ключевых» проблем всегда очень простой. Но для того, чтобы их решать с «бухгалтерской» точностью, да еще потом поддерживать информационно, необходимо осваивать очень сложные системы, а на это всегда не хватает времени, т.к. бизнес уходит вперед. Управленческие решения имеют такое свойство – если они не приняты вовремя, их ценность после наступления критической даты становится равной «нулю»!.

Поэтому в настоящее время на западном, да и на нашем рынке стали появляться программные системы и компании, реализующие принцип «экономии на времени». (Это может быть и Oracle со совей концепцией FAST Forward, но для сравнительно небольших компаний нужны еще более простые решения!)

Подобные технологии предлагают достаточно обобщенное комплексное решение, но внедряют его очень быстро и отдача заметна сразу. Это значит, что если ставится бюджетирование, то через пару месяцев у вас будет не только прописана система бюджетирования, но и будут конкретные решения по «болевым точкам» предприятия, которые связываются с системой бюджетов верхнего уровня. Т.е., если существуют, например, проблемы с управлением дебиторской задолженностью, то через 3 месяца она (задолженность) может существенно сократиться.

Да и начинать предприятию может быть надо не с внедрения системы финансового бюджетирования, а, например, с системы, предназначенной для персонала, контактирующего с клиентом или постановки управления логистикой!

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

В России на принятие управленческих решений влияют политические аспекты. Наблюдается склонность контролировать, «жандармировать» (воруют!) свой бизнес, а не контролировать цели и развитие бизнеса. Размышления руководителя необходимо увести от вопросов этики, воровства и т.д. и привести их к основным вопросам бизнеса. А основной вопрос для высшего уровня управления – стратегии развития, доли рынков и возврат вложенных средств, больше руководителя ничего не должно интересовать, он должен контролировать и прогнозировать только эти показатели.

И это еще один аргумент за скорейшее построение «верхнего» уровня системы. (Данные исследований показывают, что ERP-системы в существующем виде практически не обеспечивают информацией высший менеджмент – отсюда низкий уровень интереса к информационным проектам с их стороны)

Технологии «быстрого внедрения» и «быстрой отдачи», включающие постановку контуров маркетинга, стратегического планирования, логистики и бюджетирования финансов предлагает и БИГ-Мастер. Он позволяет быстро внедрить в этих областях менеджмента общепризнанные стандарты управления, обеспечивающие прозрачность, предсказуемость и воспроизводимость бизнеса.

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

Поэтому, в состав комплекса БИГ-Мастер, кроме традиционного Руководства пользователя по техническим возможностям продукта поставляются методические Руководства по бизнес-моделированию, а также входят услуги по бесплатному «дистанционному» консалтингу всех пользователей, заключающиеся в рецензировании создаваемых ими моделей.

Более эффективной, конечно, является совместная разработка моделей с привлечением консультантов – но это не всегда возможно из-за ценового фактора. (Подчеркнем, что разработка должна быть именно совместная, т.к. помимо результатов моделирования предприятию передаются опыт и технологии. Управление с применением бизнес-моделей это не одноразовый процесс, а «образ жизни» и делать это надо уметь и после ухода консультантов).

Тем не менее большинство предприятий принимают решение о самостоятельном внедрении продукта и это, в принципе, реально!

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

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

Кроме того, в проект должны быть вовлечены и принимать в нем активное участие практически все менеджеры среднего и низшего звена. Для подобного вовлечения желательно чтобы всем им были понятны не только цели (это обязательно!) но и технология реализации проекта. Такое ознакомление может проводиться в форме семинаров или внутренних тренингов. По ходу проекта должны фиксироваться и анализироваться промежуточные результаты, которые сами представляют значительную ценность. Внимание к такому проекту и заинтересованность в успехе должна подчеркиваться высшим руководством постоянно!

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

Фактически постановка системы менеджмента качества во многом является примером именного такого «организационного проекта», связанного с перестройкой деятельности всего предприятия. А эту перестройку не совершить тайком, силами отдела информационных технологий, департамента управления персоналом или службы качества.

И, в заключение о самой технологии бизнес-моделирования, которую мы продемонстрируем на примере создания Положений о функциональных обязанностях сотрудников (основной раздел «Должностных инструкций»), разрабатываемых с использованием организационно-функциональной модели компании.

Существует три варианта реализации этого проекта. Назовем их условно: дедуктивный (сверху-вниз), индуктивный (снизу-вверх), и «от процессов».

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

Далее, структура «черного ящика» раскрывается, и описываются существующие оргзвенья (за основу берется, например, штатное расписание). Функции последовательно детализируются с тем, чтобы функции необходимые на уровне предприятия были доведены до конкретных исполнителей. Это самый радикальный («нулевой») вариант может быть применен на сравнительно небольших (хотя и не очень) предприятиях, когда требуется серьезная перестройка бизнесов, очистка от старой неэффективной деятельности и ее носителей.

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

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

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

Устранив, неизбежные противоречия между «тремя моделями», можно перейти к следующему этапу – классификации функций по компонентам менеджмента и основным бизнес-процессам. Функции в первичных классификаторах размечаются по типам, а затем сводятся в базовые классификаторы – «функции менеджмента» (и, отдельно, «бизнес-функции»).

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

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

При этом целесообразно соблюдать определенную последовательность действий:

На первом этапе на согласование целесообразно выдавать только состав и описание функций (без учета того, за кем эти функции закреплены). Это, во-первых, позволит сосредоточиться на задаче, которая с точки зрения постановки управления очень важна – описание функционала предприятия. Во-вторых, позволит избавиться от впечатления, что это они только что делали, когда проводилось первичное анкетирование.

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

Уже на первом уровне, если не найти того, кто считает возможным ответить за всю группу функций, перед передачей на согласование их можно разделить. Это может сделать сам директор. (Например, выделить из всего административного управления выделить функции «Обеспечение документооборота на предприятии», «Юридическое обеспечение» и т.п.). То же самое и по производству, логистике и т.п. Но важно, чтобы за основу был взят один и тот же формат и перечень функций верхнего уровня – это создает единство описания предприятия.

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

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

Теперь все становится просто. Согласованные классификаторы «функций» и «бизнесов» проецируются на классификатор оргзвеньев (закрепляются исполнители). На этом, в первом приближении, заканчивается этап создания системно-функциональной модели предприятия и «Положения об организационной структуре», которое orgware с легкостью генерирует из этой модели. Дальнейшая детализация функций и звеньев (до сотрудников), и рассмотрение модели orgware в различных срезах, позволяет получить и другие базовые отчеты – например, Положение об организации маркетинговой работы, логистики или Положения о подразделениях и службах. Внизу этой «пирамиды организационного программирования» и лежат искомые Положения о функциональных обязанностях сотрудников, которые непосредственно вытекают из функций необходимых предприятию!

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

Очевидно, что после описания процессов мы получаем наиболее точный уровень знаний о деятельности конкретных сотрудников. После чего, все бизнес-операции импортируются (по –принадлежности) в существующие классификаторы функций и формально закрепляются за сотрудниками. Здесь, важно, отметить еще раз, что с помощью orgware можно сбалансировать и формально закрепить также права и ответственность сотрудников, создав тем самым реально действующие Должностные инструкции – мечту многих поколений кадровиков и управленцев.