Организация ИС: проектирование структуры

дается общий подход к построению организационной структуры и описываются некоторые конкретные примеры.

В дальнейших рассуждениях для простоты будем информационную службу называть УПРАВЛЕНИЕМ, подразделения первого уровня иерархии — ОТДЕЛАМИ, второго уровня — СЕКТОРАМИ.

Простые структурные схемы

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

1. функции,
2. клиенты,
3. продукты.

Организация по функциям

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

• отдел анализа и документирования технологий,
• отдел прикладных систем,
• отдел телекоммуникаций,
• отдел системотехники и базового ПО.

Привлекательность такого подхода состоит в следующем.

• Обеспечивается специализация. Каждый отдел выполняет ограниченный набор функций, что стимулирует эффективный обмен знаниями.
• Практически не возникает дублирования, создаются условия для стандартизации как внутри информационной службы, так и снаружи.
• Легче достигается эффективный масштаб, что особенно актуально для тяжеловесных решений на базе мэйнфреймов, и в меньшей степени, но все же важно, для клиент-серверных систем. (Под эффективным масштабом подразумевается такой размер подразделения, при котором выполнение капиталоемких функций становится экономически целесообразным. Например, пять небольших подразделений, разрабатывая ПО в рамках своих скромных бюджетов, будут использовать дешевый Microsoft Access. Объединенное подразделение, располагающее объединенным бюджетом, может позволить себе использовать дорогой Oracle.)
• Руководитель Управления облегчает себе принятие решения об исполнителях по каждой новой задаче.

Недостатки функционального подхода также хорошо известны:

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

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

Организация по клиентам

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

• отдел производственных систем,
• отдел сбытовых и маркетинговых систем,
• отдел систем учета и отчетности,
• отдел делопроизводства и систем управления кадрами.

Клиентская схема организации обеспечивает:

• Более качественное и быстрое обслуживание за счет ориентации на конкретные категории клиентов и даже отдельных клиентов.
• Более полное удовлетворение клиента за счет детального знания его потребностей и внутренних особенностей.

Недостатками клиентской схемы являются:

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

Организация по продуктам

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

• отдел разработки и сопровождения системы X,
• отдел разработки и сопровождения системы Y,
• отдел разработки и сопровождения системы Z.

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

Среди дополнительных минусов — проблема комплексного обслуживания клиента по набору продуктов.

Дополнительно к перечисленным вариантам есть еще пара способов выстраивания первого уровня иерархии Управления:

• по территориальному признаку,
• по основным внутренним процессам.

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

Сложные структурные схемы

Матричная структура "функции-клиенты"

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

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

В отношении такой структуры, несмотря на ее красивость и идейную ясность, возникает много вопросов:

• Что означают горизонтальные пунктирные линии — подотчетность, подчиненность, "зарплатные" отношения? Равноправны ли они с вертикальными отношениями?
• Как определить зону ответственности клиентов?
• Должны они быть "толстыми" или "тонкими"? Один кружок "клиент" — это один человек или отдельное подразделение?
• Что делать, если в действительности у клиента функционирует не одна, а две и более прикладных систем?
• Имеет ли смысл делить системотехнические решения по принципу функционирования в различных подразделениях? Что делать с аппаратно-программными комплексами, которые работают в нескольких подразделениях и когда затраты на приобретение такого комплекса велики?
• Можно ли разделять на отдельные сегменты телекоммуникации, когда по сути это единое образование, в большей степени привязанное к зданиям и сооружениям, нежели к внешним подразделениям?

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

1. Горизонтальные отношения ни в коем случае не могут быть равнозначными с вертикальными отношениями. Это скорее отношения подотчетности, нежели подчиненности. "Вертикальный" менеджер определяет концепцию и генеральное направление развития, выбирает инструментальные средства для достижения целей, управляет людскими ресурсами и фондом заработной платы своих подчиненных, то есть делает те вещи, что и в обычной обстановке. "Горизонтальный" менеджер, прежде всего, отвечает за выполнение конкретных мероприятий или проектов, информирует клиента о состоянии дел, уточняет постановку задачи, контролирует выполнение работ. "Горизонтальный" менеджер может также распоряжаться частью премиального фонда, но, во-первых, он обязан согласовывать свои решения с "вертикальными" менеджерами, например по принципу "двойного ключа", а во-вторых, контролируемая им часть премиального фонда не должна составлять большую часть премиального вознаграждения сотрудников. В противном случае не избежать конфликтных ситуаций.
2. Толщина кружочка "клиент" зависит, прежде всего, от тех функций, которые на него возлагаются. Задачи "горизонтального" менеджера могут сводиться исключительно к проектной деятельности, но также могут включать в себя и вопросы анализа и постановки задачи, сопровождения действующих комплексов. В простейшем случае это может быть отдельный человек, обеспеченный всем необходимым для выполнения эффективных коммуникаций. В другом случае это может быть структурное подразделение. Здесь имеются следующие подводные камни. Решая свои задачи в автономном режиме, "горизонтальный" менеджер, тем не менее, должен обладать определенным весом как в рамках Управления, так и за его пределами. Может оказаться так, что культура предприятия не приемлет подразделения, состоящего из одних только значимых должностных единиц, например главных специалистов. Возникает очевидная аналогия с офицерским полком. Тогда от такого варианта следует отказаться.
3. Если "горизонтальный" менеджер является руководителем структурного подразделения и выполняет функции системного анализа, то в этом случае могут возникнуть другие проблемы, связанные уже с культурой выполнения работ в самой информационной службе. Постановка задачи должна оформляться в виде технического задания (ТЗ), которое документирует функциональные, технические и технологические требования, условия эксплуатации, требования к программной документации. К сожалению, про систему государственных стандартов в России как-то уже не принято вспоминать, а до собственных методологических разработок руки, как правило, не доходят. В итоге разработка ТЗ дается с огромным трудом и занимает безумно много времени, что сводит на нет саму идею ускорения горизонтальных процессов. Еще одна неприятность поджидает вас, если вы решите переложить все аналитические задачи на плечи "горизонтального" менеджера, например, задачу разработки эскизного проекта, программных спецификаций и т. д. В этом случае неминуемо произойдет отрыв аналитиков от специалистов по разработке/настройке программного обеспечения с результатами, аналогичными только что описанным.
4. Передача "горизонтальному" менеджеру функций сопровождения также должна делаться с оглядкой, поскольку в этом случае велика вероятность утопить его в текущих проблемах и проблемках. При этом стратегически важные для клиента позиции могут быть упущены.
5. Предложенная "идеальная" структура хорошо работает в ситуации, когда ваши клиенты легко разбиваются на группы, в каждой из которых используют только один программный продукт, одну систему. На практике такое встречается редко, и тогда необходимо усложнять структуру. Один из вариантов такого усложнения в модели "фронт-миддл-бэк офис" будет описан позднее.
6. Разделение системотехнических и телекоммуникационных услуг на клиентские сегменты далеко не всегда является целесообразным. (В первом случае играет роль фактор эффективного масштаба, во втором — территориальные особенности размещения подразделений, отношения с собственниками площадей и так далее.) Если это окажется именно так, отделы системотехнических и телекоммуникационных услуг будут представлять собой общие "пулы" для всех "горизонтальных" менеджеров. Проблема состоит в том, что к одному начальнику такого отдела обращаются сразу несколько "горизонтальных" менеджеров, и каждый имеет определенные властные полномочия. Данная проблема решается относительно просто — контроль над выполнением проектов можно направить не через начальника отдела, а через рядового сотрудника этого же отдела, согласовав его кандидатуру с начальником.

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

Структура "фронт- миддл-бэк офис"

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

Для сокращения количества связей в данную схему вставляется центральное звено — "миддл-офис". Пример такой структуры приведен на рис. 3.

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

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

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

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

Должен отметить, что статьи на эту тему написаны автором на основе опыта, накопленного за время работы в банке "Менатеп" в 1997-1998 годах.