Проекты ИС для крупных предприятий: от бессистемного управления к системам управления знаниями

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

Михаил Владимирович Головко — главный инженер Центра информационно- прикладных систем OAO ICL-КПО ВС (г. Казань). Ему можно написать по электронной почте: MGolovko@icl.kazan.ru

Автор этой статьи уже писал о причинах некоторых преимуществ «лоскутной» автоматизации предприятий перед созданием заказных ИС и систем на основе известных ERP-продуктов [1]. А также о том, почему ни один из этих трех подходов к созданию сложных ИС предприятий не обеспечивает требуемого уровня автоматизации и качества.

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

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

Приведенное в статье описание целей СУЗ и способов ее использования может применяться при составлении набора инструкций для организации деятельности проектных подразделений по реализации и использованию СУЗ. Наиболее детально говорится о подсистеме стимулирования/мотивации сотрудников, так как действия этой подсистемы определяют возможность нормальной работы других подсистем СУЗ и нормального выполнения проекта.

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

Приоритет грамотности заказчика, или нужны ли предприятиям хорошие ИСП?

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

Пример 1. Практика показала, что весьма часто руководители и ведущие сотрудники ИТ-службы заказчика даже при помощи консалтинговых компаний не в состоянии просчитать и спрогнозировать развитие долгосрочного проекта и его риски при разных моделях финансирования.

Пример 2. На «разборе полетов» при срывах проектов подрядчики часто жалуются на неудовлетворительные технические требования к реализации ИС со стороны заказчика и с недоумением спрашивают: «Почему выдвигаемые сейчас вами требования не были зафиксированы в техническом задании ранее?» Однако если учесть, что ТЗ часто разрабатывается подрядчиком, то возникает ряд других вопросов. Почему, видя слабость заказчика, подрядчик не предлагает полноценные ТЗ? Где его отчуждаемый нормативный пакет методической и технической документации, который просто необходим для длительной, последовательной разработки? Почему этот пакет часто объявляется ноу-хау или прячется «под прилавок», почему не присутствует в прайс-листах, как товар?

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

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

Кризис управления и концепция СУЗ

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

Кроме того, добавились новые факторы, требующие пересмотра управления персоналом (который является основным носителем и знаний, и незнаний), управления проектом и ИТ:

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

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

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

Поэтому концепция СУЗ в качестве первых действий предусматривает:

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

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

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

От бессистемного управления к системе управления знаниями

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

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

СУЗ: определение

СУЗ — это система, которая целенаправленно, активно, систематически и планомерно:

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

В СУЗ входят следующие основные подсистемы:

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

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

Цели и действия по созданию и использованию СУЗ

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

Система стимулов и самоорганизованная команда

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

Исходя из сложившихся условий, я вижу два базовых сценария оплаты ИТ-сотрудников команды:

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

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

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

Величина же премий, на мой взгляд, может колебаться от 0 до 200% оклада рядовых ИТС (для них доля премии в минимально требуемой зарплате должна составлять

20-50%). Для ключевых ИТ-сотрудников и ИТ-руководителей это должен быть процент от чистой прибыли/экономии.

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

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

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

Ниже перечислены некоторые важные способы стимулирования специалистов команды.

Комбинирование оплаты с традиционными «бонусами» — предоставление или покупка жилья, различные ссуды, пакет социальной помощи, система скидок (на акции фирмы, на путевки, поездки на выставки и пр.).

Карьерный рост — четкая система повышений по службе, повышение квалификации, сертифицирование.

Условия труда весьма важны для плодотворной интеллектуальной работы, например:

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

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

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

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

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

СУЗ — это управление людьми, а не данными...

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

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

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

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