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

В статье [1] был предложен подход к классификации управленческих информационных систем (УИС), согласно которому каждую из них можно отнести к одной из следующих категорий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В подтверждение правильности сказанного выше, можно привести слова А. Рыжова (http://www.osp.ru/cw/2004/09/021_1.htm), директора по развитию Череповецкого сталепрокатного завода: "Краеугольным камнем при выборе системы должны стать стратегические цели предприятия, которые планируется достичь в ходе внедрения. Отталкиваясь от этого, нужно оценить необходимость использования новой технологии с точки зрения перспектив получения конкурентных преимуществ. Если технологическая новация и в самом деле полезна, следует определить условия, при которых станет возможно изменение ключевых бизнес-процессов, которые призвана поддержать новая технология".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В качестве примера рассмотрим несколько вариантов ситуации при которой осуществляется выбор системы***.

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

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

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

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

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

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

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

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

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

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

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

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

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

Естественно, эти факторы не могли не сказаться на качестве предоставления услуг по созданию УИС на предприятиях. Процитируем А. Тимошенко, руководителя программы ИФД "Капиталъ", занимавшегося внедрением ERP-систем в нескольких крупных компаниях (www.osp.ru/cw/2004/09/021_1.htm): "Их уровень [консультантов] со временем становится все ниже. Около 30% консультантов мало знают особенности системы, которую внедряют, и изучают ее, тренируясь на "подопытных кроликах" — предприятиях-клиентах консалтинговых компаний". "Зачастую они не понимают ваш бизнес, они лишь могут говорить с вами на одном языке".

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

Консалтинг, изначально ориентированный на создание эффективных систем управления предприятием, был переориентирован на автоматизацию текущей управленческой деятельности со всеми ее "национальными" особенностями. И в этом равная вина и тех кто заказывал создание УИС, которые аккумулировали опыт управленческих систем соответствующих примерно 30-40 годам XX века, и исполнителей заказа, соглашавшихся с заказчиком в том, что существует совершенно особенная "национальная" экономика со своей спецификой. И если поднять публикации середины 90-х годов, мы найдем там множество интервью и заявлений, посвященных этим особенностям, которые сделаны руководителями практически всех локальных (СНГ) разработчиков управленческого ПО.

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

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

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

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

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

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

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

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

ЛИТЕРАТУРА

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

2005.01.10
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".