Системы управления, УИС и ПО

• систем поддержки стратегического управления;
• систем управления эффективностью бизнеса
• (BPM);
• систем операционного управления;
• систем АСУ ТП.

В соответствии с задачам управления предприяти­ем категория систем операционного управления мо­жет быть разбита на следующие классы:

• системы бухгалтерского учета;
• системы управленческого учета;
• системы планирования и управления ресурсами или ERP-системы;
• специализированные системы.

В соответствии с основной операционной деятель­ностью предприятия, которая определяет перечень и состав бизнес-процессов, УИС можно отнести к не­которому виду.

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

И наконец, тип УИС «собирает» все дополнитель­ные характеристики, которые позволяют детализиро­вать описание системы (архитектуру и многое другое). В основном эти характеристики относятся к программ­ному обеспечению, на базе которого и создается УИС.

РАЗНИЦА МЕЖДУ УИС И ПО

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

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

Рассмотрим процесс превращения ПО в УИС (то, что обычно принято называть внедрением), стадии это­го процесса и условия его протекания.

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

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

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

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

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

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

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

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

РАЗНИЦА МЕЖДУ УИС И СИСТЕМОЙ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ

Еще два понятия, которые хотелось бы расставить на свои места: система управления предприятием и управленческая информационная система.

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

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

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

Здесь уместно использование так называемой те­ории ограничений (Theory of Constraints, TOC), позво­ляющей правильно выстроить приоритеты о которых шла речь выше. На практике применение теории дает следующее: если мы работаем над решением какой-то проблемы (меняем производственное оборудование, внедряем новую технологию или информационную си­стему и т. д.), и не получаем ожидаемого результата,— значит мы решали проблему, которая в данный момент не является самым узким местом в деятельности пред­приятия, либо, если она таковой является, для ее ре­шения мы выбрали метод, который задачу не решает.

То есть главным здесь следует считать то, что внед­рение УИС должно являться заключительным аккор­дом огромной работы по совершенствованию системы управления предприятием, а не самоцелью. С нашей точки зрения, внедрение УИС — это только часть ра­боты, и более правильно говорить о модернизации сис­темы управления предприятием в целом. Эта работа (рис. 2) обязательно включает этап формирования биз­нес-целей предприятия, анализ соответствия текуще­го состояния системы управления поставленным це­лям, этап формирования требований (причем не к УИС, а именно к системе управления предприятия в целом).

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

В подтверждение правильности сказанного выше, можно привести слова А. Рыжова, директора по развитию Череповецкого сталепрокатного завода: «Краеуголь­ным камнем при выборе системы должны стать стра­тегические цели предприятия, которые планируется достичь в ходе внедрения. Отталкиваясь от этого, нуж­но оценить необходимость использования новой тех­нологии с точки зрения перспектив получения конкурентных преимуществ. Если технологическая нова­ция и в самом деле полезна, следует определить усло­вия, при которых станет возможно изменение ключе­вых бизнес-процессов, которые призвана поддер­жать новая технология».

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

В мире бизнеса нет статики, меняется рынок — должно меняться и предприятие, его бизнес-цели, система управления и технологии. Поэтому, в идеале, работы по совершенствованию системы управления и, как следствие, по модернизации должны осуществ­ляться постоянно, а схема их реализации выглядеть примерно следующим образом (рис. 3). При исполь­зовании такого подхода все становится на свои места:

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

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

ТРЕБОВАНИЯ К СИСТЕМЕ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ И КЛАССИФИКАЦИЯ УИС

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

Существует три основных условия, которые поз­воляют сказать, что на предприятии создана УИС, к этим условиям относятся:

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

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

В качестве примера на рис. 4 представлены три ги­потетических варианта, которые позиционируются как база для создания УИС ERP-класса.

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

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

Синим представлено предложение, на базе которо­го действительно можно создать УИС ERP-класса.

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

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

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

Во всех остальных случаях, как лучший вариант, будет построена УИС низшего класса, а именно клас­са «систем бухгалтерского учета», а средства потрачен­ные на закупку более мощного ПО и процесс внедре­ния — выброшены на ветер.

Теперь рассмотрим каждый из трех компонентов подробнее.

КОМПОНЕНТЫ УИС

Функциональность ПО

Под необходимой функциональностью, в данном контексте, следует понимать реализацию базовых ал­горитмов, бизнес-функций и процедур, необходимых и достаточных для создания системы соответствующе­го класса². Чем больше данное ПО содержит таких эле­ментарных кирпичиков построения УИС, тем выше функциональность. Естественно, что эти объекты (кир­пичики) могут быть как достаточно мелкими элемен­тарными, так и крупными, к примеру блок APS или MRP. Во время создании УИС, на основе бизнес-ло­гики строятся связи между этими кирпичиками.

Зависимость между принадлежностью системы к определенному классу и функциональной полнотой прослеживается по набору и направленности реали­зованных в системе блоков.

Если в ПО отсутствуют представление и операции над объектами учета и планирования в натуральных показателях, причем с автоматическим пересчетом в заданные, необходимые в конкретном случае едини­цы измерения, то речь идет о ПО бухгалтерского клас­са. Если в ПО отсутствуют блоки, обеспечивающие планирование ресурсов в натуральных показателях, его никак нельзя отнести к системам класса ERP.

В принципе системы более старшего класса (ERP) включают в себя всю функциональность, присущую системам младшего класса (учетные).

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

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

Если посмотреть на системы, разрабатываемые в СНГ, то 90% из них строились от бухгалтерского (фискального) или материального (складского) уче­та. Соответственно и наибольшая функциональность достигнута именно в реализации этих направлений. Значительная функциональность наработана в бло­ках, реализующих хитросплетения локальных прин­ципов начисления заработной платы и фискального учета основных средств. Многое из этого с точки зре­ния управления бизнесом является чрезмерно услож­ненным и запутанным, но с точки зрения соответствия фискальным требованиям использование такого ПО в качестве готовых блоков для подготовки фискальной отчетности представляется весьма эффективным.

Гибкость бизнес-логики

Чем больше в системе возможностей по перестрой­ке бизнес-логики без модернизации кодов ПО, тем вы­ше гибкость.

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

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

Аналогичная проблема возникает и в случае ис­пользования идеологии АРМов, когда вся бизнес-ло­гика вынесена на клиентские места и необходимо син­хронизировать действия независимых пользователей.

Так, к примеру, если обратиться к ранним реклам­ным материалам компании «Галактика», то можно увидеть, что первые версии их системы строились как набор АРМов, связанных электронным докумен­тооборотом, синхронизирующим действия пользова­телей. Кстати, отсюда очевидно появился и специфи­ческий термин «контур», по которому перемещаются документы.

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

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

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

Квалификация консультантов

В ситуации, когда предприятие покупает УИС, ча­ще всего оно просто приобретает ПО, только после его успешного внедрения можно говорить, что на пред­приятии появилась УИС.

Как показывает наш анализ публикаций, посвя­щенных внедрениям управленческих систем на тер­ритории СНГ, в большинстве своем внедрение ПО не внесло никаких изменений в систему управления пред­приятия, не позволило добиться ощутимых конкурент­ных преимуществ.

Хотя заказчики часто обвиняют недобросовестных консультантов, некачественное ПО, кадровый голод на предприятии (и во многом справедливо), необхо­димо отметить, что вина во многом лежит и на заказчике. Они либо устраняются от работы по внедрению, ожидая чуда, либо требуют точного отображения в УИС неэффективной системы управления, не отвечающей целям бизнеса предприятия.

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

ВЛИЯНИЕ ИНТЕРЕСОВ РАЗЛИЧНЫХ ГРУПП

Обычные проблемы, связанные с человеческим фактором, при создании на предприятии управленче­ских информационных систем усугубляются тем, что представлены интересы не двух сторон, а как мини­мум трех:

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

Интересы наемного персонала

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

ИТ-подразделение. Варианты интересов персона­ла могут развиваться по следующим сценариям:

(1) Сотрудник стремится приложить все усилия для того, чтобы была выбрано ПО одного из лидеров рынка — SAP, Oracle (изучить систему за счет пред­приятия, освоить на практике и уйти — желательно в западную компанию с соответствующим окладом). Как правило, это не очень успешные предприятия, часто или государственные, или с большой долей государст­венной собственности. Проявление — полная сосре­доточенность на личных целях, конфликтности с кон­сультантами нет. Возможны прямые потери собствен­ника, связанные с завышением стоимости проекта.

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

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

Функциональное подразделение. Интересы пер­сонала могут развиваться по таким сценариям:

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

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

Подразделения основного операционного цикла. Интересы персонала могут развиваться, например, по следующему сценарию:

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

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

Интересы консультантов

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

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

Естественно, эти факторы не могли не сказаться на качестве предоставления услуг по созданию УИС на предприятиях. Процитируем А. Тимо­шенко, руководителя программы ИФД «Капиталъ», занимавшегося внедре­нием ERP-систем в нескольких круп­ных компаниях: «Их уровень [консуль­тантов] со временем становится все ни­же. Около 30% консультантов мало зна­ют особенности системы, которую внедряют, и изучают ее, тренируясь на «подопытных кро­ликах» — предприятиях-клиентах консалтинговых компаний». «Зачастую они не понимают ваш бизнес, они лишь могут говорить с вами на одном языке».

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

За это время была создана «национальная» терми­нология, позволяющая на равных сравнивать 1:С и SAP R/3, не системы ERP-класса, а КИС. Придуман «оперативный» учет, призванный расширить область применения систем класса бухгалтерского учета за пре­делы бухгалтерии. Был придуман термин «контур уп­равления», изначально привязанный к замкнутым по­токам электронного документооборота в АРМ-ориен­тированной системе.

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

Интересы собственников

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

И в этой ситуации только активное участие самого собственника в процессе выбора ПО и поставщиков, создает предпосылки для успешного создания УИС. А единственным условием успешности участия явля­ется наличие сформированных и ясно понимаемых все­ми бизнес-целей предприятия.

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

ЛИТЕРАТУРА

[1] М. Черненко, С. Слепцов. Принципы класси­фикации управленческих информационных систем // Корпоративные системы.— 2004.— №1.

Об авторах:

Маргарита Черненко — бизнес-аналитик, Бюро Бизнес Инжиниринга
Степан Слепцов — аналитик, Бюро Бизнес Инжиниринга

¹ См. А. Бернатович. ИТ-тендеры в Украине // Корпоративные системы.— №6.— 2003.

² Любители объектно-ориентированного подхода могут использовать по­нятия объекты или классы, реализующие эти объекты.

³ Случаи, связанные с откатом, не рассматриваются.