Заметки об организационной структуре информационного центра

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

Ключевые моменты

Зачем снова нужны информационные центры

Сергей Львович Гладков - зам. начальника отдела программного обеспечения Государственного производственного предприятия «Красноярскавтодор», E-mail: sergey @avtodor.krasnoyarsk.su

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

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

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

Задача оргструктурного строительства

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

Более известны и не раз были описаны и другие типы функций, закладываемых в основу структурного деления ИЦ или подобного подразделения. Одно из таких описаний можно найти, например, в полезной статье А. Рассказова [1], где за основу структуры ИЦ взяты те или иные характеристики предметной области проекта (части и элементы системы управления заказчика, подразделения-клиенты, и т. д.).

Как бы не наступить на старые грабли

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

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

Анализ традиционной схемы учета результатов труда

Характеристика соотношений затрат

Традиционное планирование затрат, или составление сметы работ, основано на прогнозировании времени выполнения работы исполнителем работ (В_ис), времени использования вычислительных ресурсов (В_вр), средней цене исполнителя работы¹ (Ц_ис) и цене вычислительных ресурсов, используемых при выполнении работы² (Ц_вр). Тогда затраты ЗР на выполнение работы Р определяются так:

З_Р= В_ис,Р * Ц_ис,Р + В_вр,Р * Ц_вр,Р.

Но работы по информационному обслуживанию включают в себя несколько категорий работ, связанных со стадиями проектирования и жизненного цикла системы (ТЗ, ТП, РП, ОИО, ПИО - см. сноску)³, каждый из которых характеризуется своей структурой затрат. Так, для первой стадии проектирования - ТЗ, характерно соотношение В_ис,ТЗ * Ц_ис,ТЗ >> В_вр,ТЗ * Ц_вр,ТЗ, т.е. затраты труда намного превышают затраты на использование вычислительной техники.

Для стадии рабочего проектирования обычно соблюдается В_ис,РП * Ц_ис,РП≈В_вр,РП * Ц_вр,РП, то есть затраты труда исполнителей и использование вычислительных ресурсов сравнимы между собой с некоторыми колебаниями в ту или иную сторону.

Для стадии промышленного информационного обслуживания характерно В_иc,ПИО * Ц_ис,ПИО << В_вр,ПИО * Ц_вр,ПИО, т. е. преобладающей статьей затрат являются затраты на использование вычислительных ресурсов.

Пример влияния соотношений затрат

Посмотрим, к чему приводило существование указанных выше соотношений в случае конкретного ИЦ. Данные собраны автором этой статьи в процессе его работы начальником системного отдела РПНО «Таджикагропромавтоматизация» (использовались машины ЕС ЭВМ). По причинам, указанным ниже, автор хочет использовать данные реального ИЦ середины - второй половины 80-х годов.

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

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

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

Конечно, может быть, в отдельных ИЦ соотношения объемов работ и уровней их оплаты настолько изменились, что мотивируют людей совсем не так, как прежде. Но для того, чтобы такие изменения реально вошли в жизнь, надо, например, в два раза повысить зарплату аналитикам и постановщикам и в два раза снизить удельную стоимость оборудования и обслуживания. А этого пока на практике не наблюдается.

Рис. 1. Средняя выработка по категориям работ

Но вернемся к примеру. Влияние различий в структуре затрат на каждой стадии информационного обслуживания иллюстрирует рис. 1.

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

Таблица содержит реальные цифры изменения средней выработки в отделе системного проектирования за период с 1984 по 1987 год. Анализ показал, что рост выработки произошел из-за того, что отдел системного программирования из отдела разработки рабочих проектов в 1984 году превращался в отдел промышленной эксплуатации задач в 1985, 1986, 1987 годах, так как роста средней зарплаты, сопоставимого с ростом выработки, в этот период не наблюдалось. Отмеченный рост средней выработки происходил благодаря методичному «давлению» плановиков, постепенно повышавших величину плановой выработки. Таким образом, планирование в усредненных объемных показателях поддерживает тенденцию снижения объема проектных работ, препятствует снижению себестоимости работ в ИЦ и создает условия для завышения цен на информационные услуги, например, путем фактического перерасхода машинного времени.

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

Итак,

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

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

Можно ли обойтись без проектных работ?

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

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

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

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

Согласование работы проектных и производственных служб

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

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

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

Здесь я сделаю небольшое попутное замечание. Уменьшение себестоимости не может быть безусловной единственной целью; надо учитывать, что при полномасштабном проектировании оргструктуры должны закладываться средства и структуры обеспечения итогового качества предоставляемой информации.

Какая структура ИЦ может быть эффективной

Высказанные выше соображения позволяют перейти к определению основных характеристик целесообразной и обоснованной организационной структуры ИЦ.

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

Наиболее адекватным организационным решением этого конфликта является так называемая матричная структура ИЦ, приведенная на рис. 2⁴. Этот вариант матричной структуры явно отличается от «обычных» матриц для компьютерных фирм или подразделений, например от матрицы, рассмотренной в [1].

Конечно, предложенное разделение не может исключать создание узкопрофессиональных сообществ и групп, например, тех же сетевиков или специалистов по базам данных, системных программистов, создающих программное обеспечение универсального назначения. Но такие группы могут создаваться на втором уровне функционального деления, а сообщества вполне могут действовать в рамках всего ИЦ. Предлагаемое здесь устройство структуры ИЦ более ориентировано на экономическую и проектную специфику работ. Можно сказать, что оно направлено и на улучшение качества конечной продукции за счет уменьшения возможных искажений в создаваемой системе. Это происходит по той причине, что предложенное функциональное деление хорошо соответствует органичному разделению труда, рассмотренному в модели «Диполь++» [3].

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

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

Но, как пел Булат Окуджава, - «это, братцы, о другом».

Литература

[1] Рассказов А. Н.. Организация Информационной Службы: проектирование структуры. (Директору Информационной службы)// Computerworld Россия 23 марта 1999г, №10(171), с. 34) или (http://www.osp.ru/cw/cio/1999/05/04.htm).

[2]Бондарь Н. П., Васюхин О. В., Голубев А. А., Подлесных В.И. Эффективное управление фирмой: современная теория и практика. СПб.: Изд. дом «Бизнес-пресса», 1999. 416 с.

[3] Зиндер Е. З. Диполь Тыугу // Computerworld Россия 6 апреля 1999, №12(173).