Постановка цели и задач организации менеджмента и построения организационной структуры судоходной компании

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

Основные направления совершенствования организации менеджмента и построения организационных структур судоходных компаний в настоящее время состоят в следующем:

- компаний изменяются от функциональной организации к организации, основанной на центрах прибыли;

- организации становятся ближе к клиентам (судоходная компания “Си-Лэнд” уменьшила число слоев управления с 12 до 8, чтобы улучшить отзывчивость на требования клиентов. Одной из главных целей реорганизаций судоходной компании “Американ Президент Лайнс” было улучшение отношений с клиентами);

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

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

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

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

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

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

· анализ бизнес-процессов

· реинжиниринг бизнес-процессов

· создание технических и программных архитектурных решений

· планирование работ по созданию и адаптации программных систем

· управление ходом выполнения проектов (рейсов)

· разработка программных систем

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

В разработке прикладных систем -

· Разработка приложений (Custom Development - CDM)

· Организация разработки приложений (CustomPLUS - CPM)

· Техническая архитектура информационной системы организации (Enterprise Technical Architecture Method - ETAM);

В управлении проектами-

· Управление проектами (Project Management - PJM)

· Управление программами (Program Management - PGM)

· Управление созданием информационной системы организации (Enterprise Solution Method - ESM)

· Масштабируемое управление проектами (Scaleable Project Management - SPM);

В создании приложений -

· Внедрение приложений (Application Implementation - AIM);

В хранении данных/OLAP -

· Создание хранилищ данных (Data Warehouse Method - DWM);

В консалтинге -

· Реинжиниринг бизнес-процессов (Business Process Reengineering - BPR)

· Планирование стратегии информационной системы (Information System Strategy Planning - ISSP)

· Управление организационными изменениями (Organisational Change Management - OCM)

· Управление практической деятельностью (Practice Management - PCM)

· Управление предложениями (Proposal Management - PPM)

Методология “Реинжиниринг бизнес-процессов” BPR определяет набор настраиваемых процессов для организации работ по эффективному реинжинирингу (перестройке) деловой активности предприятия. Эти процессы покрывают планирование, контроль качества, управление этапами проекта.

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

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

· гибкий рабочий план проекта, позволяющий учитывать все важнейшие показатели

· метод управления проектом

· соответствующее программное обеспечение

· консультационные методические материалы

Методология “Планирование стратегии информационной системы” ISSP определяет подход формирования стратегии информационной системы по вопросам технологии, приложений и инфраструктуры.

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

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

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

Методология ISSP решает следующие задачи:

· Определение деловой стратеги предприятия и движущих сил ее реализации для создания наилучшей стратегии построения информационной системы

· Выявление лучших решений в разрезе информационных систем на аналогичных предприятиях той же самой индустрии

· Определение показателей производительности информационной системы, по которым будет производиться оценка производительности внутри предприятия

· Исследование текущих стандартных индустриальных технологий, систем и приложений

· Исследование перспективных направлений развития индустрии и технологических тенденций

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

· Выявление лучших имеющихся информационных систем

· Определение стандартов определения и повышения квалификации персонала

· Создание перспективных планов создания и развития информационной системы и технологий на предприятии

· Эффективное описание информационной системы предприятия

· Анализ бизнес процессов и информационных потоков

· Выбор технологии, приложений и инфраструктурных элементов реализации стратегии информационной системы

· Выработка наилучших принципов для реализации процессов методологии ETAM

Методология “Управление созданием информационной системы организации” ESM нацелена на создания интегрированного решения, что в условиях крупного предприятия достигается крайне сложно. На крупных предприятиях многие бизнес-процессы могут возникать хаотично и не быть между собой связанными. Это происходит вследствие автономности и независимого развития различных подразделений. Создание общих бизнес-процессов и условий согласованного выполнения программ и подготовки отчетов может существенно повысить эффективность системы.

ESM регламентирует все этапы процесса создания информационной системы:

· анализ

· выбор решения

· приобретение готового решения

· разработка собственного решения

· интеграция

· тиражирование

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

· закрытые приложения

· собственные прикладные программы

· дополнительные закрытые программы сторонних производителей

· дополнительные собственные прикладные программы

· техническое обеспечение по обработке данных

· управление организационными изменениями

· коммуникации

· оперативная инфраструктура информационной системы

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

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

Вторая стадия - это создание реализации. На этом этапе детализируются требования и разрабатываются основные компоненты.

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

Финальная стадия - это тиражирование реализации. После того, как реализация утверждена и одобрена, она тиражируется.

Методология “Техническая архитектура предприятия” ETAM используется для создания структуры информационного окружения предприятия. ETAM предполагает:

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

· анализ, на базе которого определяются все значимые компоненты

· проектирование архитектуры информационной системы предприятия

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

Второе назначение ETAM - детальный анализ существующих архитектурных компонент и выработка детальных планов по их перепроектированию.

Третье назначение ETAM - проектирование архитектуры каждой архитектурной компоненты.

Четвертое назначение ETAM - создание прототипов или пилотных реализаций.

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

Методология ETAM направлена на решение следующих задач:

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

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

· Создание концепции предполагаемой технической архитектуры

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

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

· Создание детального плана разработки подсистем, реализующих намеченную архитектуру

· Инициирование процессов поддержания архитектуры информационной системы предприятия

Методологии разработки AIM, CDM и DWM соотносятся с методологией ETAM следующим образом:

· Принятие за основу технических решений, принципов и стандартов, определенных в ETAM.

· Создание детальной архитектурной спецификации для каждого проекта на основе прототипов из ETAM

· Выявление важных технических аспектов проектов, которые необходимо включить в ETAM

· Утверждение окончательной архитектуры проектирования, создаваемой на основе ETAM

· Предоставление деталей проектирования системы в информационный репозиторий ETAM

ETAM базируется на наборе следующих взаимосвязанных между собой процессов:

· Анализ деловой активности предприятия (Enterprise Business Analysis - BA)

· Информационная архитектура (Information Architecture - IA)

· Архитектура приложений (Application Architecture - AA)

· Архитектура распределенных сервисов (Distributed Services Architecture - DS)

· Архитектура компонент (Architecture Component Selection - CS)

· Архитектура платформ (Platform Architecture - PA)

· Инфраструктура операционных систем (Operating Infrastructure - OI)

Теоретически ETAM позволяет:

· снизить риски

· принимать обоснованные решения по приобретению технологических компонент

· понизить стоимость работ

Методология “Разработка прикладных систем” CDM формулирует подход к созданию прикладных систем. CDM регламентирует все стадии создания приложений: определение бизнес-потребностей, детализированный анализ задач и системы, дизайн и генерацию приложения.

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

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

CDM включает следующие компоненты:

· Шаблоны для автоматизации проектирования

· Библиотеку стандартов и рекомендаций

· Метод организации работ

· Метод управления работами

Методология “Управление программами” PGM позволяет спланировать, организовать и управлять разработкой и внедрением сложных больших программных систем, распадающихся на множество проектов. PGM регламентирует требуемую инфраструктуру, механизмы контроля и подходы к разработке, внедрению и поставкам, необходимые для успешного создания и интеграции крупномасштабных приложений.

PGM является методологией, регламентирующей применение методологии управления PJM и разработки CDM/AIM.

Методология “Управление Проектами” PJM определяет контрольные точки для управления качеством и процесса реализации внутри этапов проекта и позволяет координировать выполнение проектных работ, объединенных общей задачей. Взаимосвязи между фазами и процессами выглядят примерно так, как это показано на рис. 1.

Рис. 1. Взаимосвязь между фазами и процессами

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

Рис. 2. Структура методологии Управления Проектами

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

Контролирующие под процессы выполняются одновременно с Задачами Выполнения. Контроль устанавливает степень достижения целей путем:

· определения производительности и качества

· отслеживания выполняемых процессов

· управления изменениями в постановке задачи

· управления результатами и рисками

· внесения требуемых корректив.

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

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

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

Диаграмма 3. Процессы PJM

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

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

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

Процесс Управления Качеством определяет критерии качества для обеспечения соответствия проекта заданным целям и ожиданиям на протяжении всего жизненного цикла проекта.

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

Методология “Внедрение приложений” AIM направлена на управление проектами максимально быстрого и высококачественного внедрения приложений. AIM регламентирует все основные стадии ведения проекта от этапа определения целей и стратегии до сопровождения новой системы.

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

Совместное использование методик “Разработка прикладных систем” и “Внедрения Приложений” дает положительные результаты при адаптации пакета прикладных программ к специфическим нуждам организации.

Методология “Масштабируемое управление проектами” SPM предназначена для управления планированием, контролем и завершением всех проектов и программ, независимо от их размера и сложности. SPM, базируясь на задачах управления PJM и PGM, определяет набор задач управления, связанных с распределением обязательств и ролей, контролем за ними, и их аннулированием после завершения проектов.

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

Методология SPM является развитием методологии PJM.

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

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

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

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

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

Далее последовательно изучаются:

· географическая, организационная и функциональная распределенность системы

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

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

Хотя DWM была создана для создания корпоративных хранилищ данных, она применима в проектах создания витирин данных.

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

Методология “Организация разработки приложений” CPM ориентирована на менеджеров проектов и предназначена для преобразования организационной структуры подразделений разработки информационных систем с целью повысить эффективность их работы.

Методология “Управление организационными изменениями” OCM затрагивает технические и деловые организационные аспекты предприятия. OCM определяет организационную готовность к изменениям и указывает, какие улучшения необходимы для безболезненного перехода на новую систему. В рамках OCM регламентируются следующие вопросы:

· распределение ролей и ответственности

· механизмы информирования персонала об изменениях и обратная связь

· оценка эффективности организации и персонала

· проверка компетентности менеджеров для выполнения новых обязанностей

· организация обучения конечных пользователей

· организация программы стимулирования персонала к внедрению изменений

Методология “Управление практической деятельностью” PCM направлена на повышение мастерства консультантов, их повышение по службе, создание наборов продуктов и сервисов, необходимых заказчику.

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

Тиражирование решений будет проходить в соответствии с методом Fast Forward, являющимся специализированным вариантом методологии внедрения - Application Implementation Methodology (AIM). В результате стандартизации применяемых решений и максимального использования ресурсов, период внедрения по технологии Fast Forward существенно короче традиционной AIM и, как результат, значительно дешевле в исполнении.

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

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

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

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

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

На Рис. 3 представлена схема процессов в соответствии с AIM. Процессы выполняются параллельно и их перехлест зависит от характера задач и наличия ресурсов.

Рис.3 Процесс организации задач в AIM

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

· Определение рабочих требований

· Распределение рабочих требований

· Планирование приложений и технической архитектуры

· Проектирование и Построение Модулей

· Конвертация данных

· Документирование

· Тестирование рабочих процессов

· Тестирование функционирования системы

· Обучение

· Переход на новую систему

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

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

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

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

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

· Приложений: ИС, третьей стороны и специализированных баз данных для поддержки приложений;

· ключевых интерфейсов предприятия и дистрибутивов для приложений, серверов и центров данных;

· вычислительной техники, включая серверы и персональные компьютеры для клиентов;

· сетей и инфраструктуры для передачи данных.

Ясная и хорошо спроектированная архитектура информационной системы является определяющим фактором успеха любого проекта внедрения. Архитектура информационной системы должна удовлетворять следующим требованиям:

· соответствовать рабочим и техническим требованиям;

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

· реалистично оценивать возможности и ограничения технологии, на которой она базируется.

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

· оптимальной конфигурации внедряемых приложений;

· согласованной работы приложения на имеющемся оборудовании и сети;

· функций и процедур, необходимых для управления системой в целом.

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

Процесс Проектирования и Построения Модулей (MD&B) предназначен для создания заказных (т.е., ориентированных на специфические технические требования) систем, с целью восполнения недостающих функциональных возможностей, сформулированных при составлении требований к бизнес-задачам системы. Заказные системы включают в себя программные модули (формы, отчеты, крупномасштабные изображения, блоки предупреждения, устройства запуска баз данных и т.д.), которые должны быть спроектированы, построены и испытаны до того, как они будут включены в общую систему прикладного программного обеспечения. Процесс MD&B нацелен на проектирование и разработку заказных модулей; процесс Business System Testing (испытания бизнес-систем) предназначен для обеспечения испытаний заказных модулей.

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

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

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

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

Процесс Проверки Работоспособности помогает группе внедрения определить, подготовить и выполнить проверку характеристик на системе, специально подготовленной для тестирования. Процесс испытаний не предполагает какого-либо определенного объема испытаний: группа внедрения может использовать один и тот же процесс для проведения сложного испытания на системе в целом, или более простого испытания на каком-либо компоненте или части системы. Группа может, кроме того, проводить этот процесс на объекте более одного раза, при различных объемах и целях тестирования, для проверки характеристик системы в различных ее аспектах. Цели каждого такого процесса и его относительные характеристики по времени, в пределах данного объекта, могут отличаться, а метод который используется группой, может быть одинаковым. Этот процесс предоставляет мощное средство оценки характеристик качества системы или некоторой ее части до момента сдачи ее заказчику.

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

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

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

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

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

В процессе перехода предприятие переключается на новую систему. По завершении этого процесса новая система используется для контроля деятельности предприятия и перспективного планирования.

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

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

Диаграмма 4. Диаграмма метода AIM

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

Дата добавления: 2014-01-04