Формирование целевой архитектуры КИС судоходной компании

Введение

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

Инструментом фокусировки для ИТ подразделения является ИТ стратегия компании, где рассматриваются:
1. Участники.
2. Обязательства:
– активы и права на них;
– эффекты;
– обязательства.
3. Архитектура:
– приложений (прикладная);
– информационная;
– техническая;
– окружения.
4. Организация ИТ службы.
5. Проекты, направления деятельности.

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

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

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

Эти задачи являются первыми шагами в направлении формирования ИТ стратегии компании.

В рамах данной работы не рассматриваются следующие вопросы:
1. Архитектура:
– технологическая;
– окружения;
– информационная.
2. Построение ИТ службы.
3. Обязательства:
– активы и права на них;
– обязательства.

О компании

«Мурманское государственное морское сухогрузное и пассажирское пароходство» образовано 22 сентября 1939 года (c 1967 года «Мурманское морское пароходство»). С 1993 года преобразовано в акционерное общество открытого типа со смешанной формой собственности и является правопреемником государственного предприятия «Мурманское морское пароходство».

ОАО «Мурманское морское пароходство» играет ключевую роль в доставке грузов в арктические районы России, выполняя до 80% грузоперевозок на трассах Северного морского пути.

На рынке транспортных услуг среди российских судовладельцев доля грузоперевозок флотом Мурманского пароходства в общем объеме перевозок судами под российским флагом составляет 40%.

Основные направления деятельности:
• Перевозки морским транспортом грузов и пассажиров на международном и внутреннем сообщениях.
• Рейдовая перевалка нефти.
• Буксировка объектов.

Численность сотрудников: около 2 500 человек (береговые сотрудники, морские специалисты).

Флот компании насчитывает:
• сухогрузный — 22 судна;
• танкерный — 7 судов;
• пассажирский — 2 судна;
• ледокольный — 1 судно.

Методология

Термин «ИТ-архитектура» может означать множество близких по смыслу, но, тем не менее, различающихся понятий. Известных формальных определений архитектуры cyществует несколько сотен. В этой работе под архитектурой системы понимается определение, данное в стандарте ANSI/IEEE 1471-2000. Архитектура системы – это "фундаментальная-организационная структура системы, воплощенная в ее компонентах, их взаимоотношениях между собой и с окружением, и принципы, управляющие ее построением и эволюцией".

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

Существуют множество методик (то, что по-английски называется frameworks) описания и совмещения архитектур. Обширный обзор методик и подходов к описанию архитектуры приведен в [1], с. 205. Однако, большая часть методик сложна и будет с трудом восприниматься без соответствующей подготовки. Необходим простой язык, одинаково хорошо понимаемый и сотрудниками ИТ-службы и руководителями предприятия, подразделений.

Таким простым, но в то же время мощным языком является язык «бизнес-рамок» (frameworks), описанный в [2].

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

Следует отметить, что «бизнес-рамка» не предназначена, чтобы объяснить «как это работает». Её задача распределить ответственность за результат, согласовать цели и границы, определить проекты. Это язык совмещения архитектур и не более того.

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

Построение существующей ИТ-архитектуры

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

По результатам анализа были выявлены 4 крупных бизнес-проблемы, на которые может повлиять ИТ.

Далее можно приступать к построению существующей прикладной ИТ-архитектуры и совмещение её с бизнес-проблемами.

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

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

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

Следующий шаг по построению текущей архитектуры – нанесение на «бизнес-рамку» проблем.

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

Дополнительно, для последующего анализа на текущую прикладную ИТ-архитектуру переносятся бизнес-проблемы.

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

Построение целевой ИТ-архитектуры

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

Здесь как раз и проявляется преимущество «бизнес-рамок», позволяющее наглядно совместить различные представления архитектуры предприятия.

На этапе построения целевой прикладной архитектуры были выделены только те приложения, которые связаны с бизнес-проблемами и задачами. Была проведена ревизия и анализ функционала существующих приложений. При анализе задавался вопрос: «Позволяет ли существующий функционал приложения решить поставленные проблемы, задачи?». Если ответ отрицательный, значит это приложение необходимо доработать или вообще ликвидировать и создать новое с абсолютно новым функционалом.

Результатом этого анализа стала целевая прикладная ИТ-архитектура и сравнение её с текущей.

Формирование портфеля проектов

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

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

Основные элементы портфеля проектов и зависимости между элементами можно отразить на следующей диаграмме (рис. 1).

Рис. 1. Элементы портфеля проектов и взаимосвязи между ними

В первую очередь портфель проектов строится на основании сравнения ИТ-архитектуры «как есть» и «как будет». Необходимое условие при формировании портфеля проектов: каждый проект или несколько взаимосвязанных проектов должны решить как минимум одну бизнес-проблему. У каждого проекта присутствуют реквизиты:
1. Наименование проекта
2. Перечень решаемых бизнес-задач или проблем
3. Перечень функциональных задач «бизнес-рамок»
4. Участники проекта (береговые подразделения, судно)
5. Спонсор проекта
6. Приоритетность
7. Исполнители (сами или внешний подрядчик)
8. Срок ввода в эксплуатацию

Часть этих реквизитов (п. 1-5) определяются автоматически на основании ранее построенных «бизнес-рамок», а часть (п. 6-8) на основании анализа и знаний о деятельности компании.

Приоритеты портфеля проектов определялись на основании критериев, изложенных в виде вопросов:
• Какой проект затрагивает максимальное количество проблем и задач?
• Проявляет ли явный интерес (выраженный вербально) бизнес к задаче, проблеме?
• Есть ли прямая связь между доходами, расходами, рисками, возможностями компании и результатом проекта?
• Может ли проект быть выполнен своими силами или нет?

По результатам анализа ответов на поставленные выше вопросы, приоритетными признаны 2 проекта:

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

Исполнителями практически всех проектов (кроме одного) является внутренняя Служба ИТ. Это связано с:

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

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

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

Заключение

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

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

1. Выявлены эффекты и механизмы влияния ИТ на бизнес. Наиболее существенные эффекты связаны с:
   • предоставлением возможности сохранения и увеличения доходов за счет внедрения модуля ТОРО (проект «Техобслуживание»);
   • снижением рисков возникновения убытков за счет замены комплекса технологически устаревших бухгалтерских и финансовых задач;
2. Сформирована целевая прикладная ИТ-архитектура, позволяющая решить задачи и проблемы, стоящие перед компанией;
3. Определены приоритеты в деятельности ИТ-службы по формированию прикладной ИТ-архитектуры. Приоритетными являются направления, которые напрямую связаны или с получением доходов или с рисками возникновения убытков:
   • разработка и внедрение модуля «Техобслуживание», позволяющего решить сразу 3 бизнес-задачи. Наличие этого модуля также позволит соответствовать внешним требованиям со стороны фрахтователей [3] и, как следствие, создает возможности для получения доходов;
   • замена комплекса бухгалтерских и финансовых приложений, написанных в устаревших средствах (Clipper). Позволит уменьшить риски несвоевременной выдачи отчетности (и, как следствие, штрафы) в контролирующие органы, исключить зависимость от персонала.
4. Построен портфель проектов для перехода к целевой прикладной архитектуре.

По результатам выполненной работы началась работа по реализации портфеля проектов.

Следует отметить, что построенный портфель проектов не является статичным. Любая стратегия, планы с течением времени требуют уточнений, корректировок, создания новых планов в связи с изменяющимися условиями. Поэтому в перспективе планируется введение регулярного процесса пересмотра, уточнения портфеля проектов в связи с:
1. Реализацией запланированных проектов.
2. Возможных изменениях в:
• в самой службе ИТ;
• приоритетах бизнеса;
• горизонте планирования;
• конъюктуре рынка.

Литература

1. А. Данилин, А. Слюсаренко. «Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия. – М.: Интернет-Университет Информационных Технологий, 2005. – 504 с.
2. Ананьин В.А. Материалы курса «ИТ-стратегия и бизнес-стратегия фирмы», Школа IT-менеджмента АНХ при Правительстве РФ. 2008.
3. «Tanker management and self assessment», www.ocimf-tmsa.com

Copyright © 2009 Сенченко О.Б.