Модель Дж. Хендерсона позволяет сделать следующие выводы:

•         существует взаимодействие основных бизнес- и ИТ-платформ;

•         если основная бизнес- или ИТ-платформа изменяется, то маловероятно, что соответствующая наследуемая ИТ-архитектура сохранится;

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

В табл. 1.2. представлено взаимное соответствие бизнес-архи­тектуры и ИТ-архитектуры организации.

Для перехода к анализу ИТ и методов проектирования ИС необходимо рассмотреть влияние рыночной динамики и РБП на применение ИТ, например в рамках изложенной выше схемы Дж. Хендерсона. Дело в том, что если динамика рынка заставляет корпорацию делать реинжиниринг основных видов деятельности, т. е. менять бизнес-платформу, то при этом должна измениться не только архитектура организации, но и ИТ-платформа. Это бывает в случае, если предприятие переходит от торговли продук­тами питания к работе в области, например, телекоммуникаций.

Сопоставление бизнес- и ИТ-архитектуры в современных условиях

Таким образом, могут быть сделаны следующие выводы.

•         Методы проектирования ИС должны обладать гибкостью для обеспечения живучести предприятия в условиях бизнес-ре­инжиниринга.

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

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

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

•         Методология и методы проектирования должны радикально

•         отличаться от классических.

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

1.4.2. Новое системное проектирование процессов

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

Рис. 1.10. Взаимосвязь составных частей НСП

А - новых ИТ и методов проектирования систем, не связан­ных прямо с организационно-производственными приложе­ниями;

В - бизнес-реинжиниринга как реконструкции управления предприятием;

С - социопсихологии, психологии труда и других методов учета «человеческого фактора».

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

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

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

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

Особенность этой схемы состоит в том, что каждый из трех источников приобрел некоторую критическую массу свойств. Степень пересечения и взаимопроникновения этих источников во много раз увеличилась даже по сравнению с восьмидесятыми годами XIX в. В результате возникло пересечение всех трех источ­ников - область ABC, которая и представляет собой область НСП.

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

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

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

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

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

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

2. Аналитический раздел

2.1 Краткий анализ и описание объекта управления

Российская компания ES (до 1997 года E Software) основана в 2002 г. студентом 2 курса ЖАТ и на сегодняшний день является одним из ведущих российских разработчиков технологий прикладного программного обеспечения для Teamcenter.

Компания ES обладает широким спектром собственных технологий в сфере разработки ПО для системы Teamcenter и на их основе создает различные программные продукты. Разработка технологий и программных продуктов ES производится в Москве.

2.1.1. Основные характеристики объекта управления

В настоящее время в компании ES работают лучшие специалисты по системе Teamcenter.

Офис компании ES находится в Москве. Продукты и решения компании ES доступны во многих странах мира благодаря собственной сети партнёров и представителей.

За годы работы компании инвестиции в разработку составили более 500 человеко-лет.

Наиболее известные продукты ES:

    * Easy Teamcenter – модификация TeamCenter с более дружественным интерфейсом пользователя;

    * ELOIZ – программный пакет для Teamcenter, в который вошли десятки дополнительных утилит, улучшений, шаблонов;

По данным исследований ES, ежегодно около 10000 частных пользователей и сотни организаций пользуются программными продуктами компании. Ежегодная экономия от использования продуктов и технологий ES в мире составляет около 100 тыс. человеко-часов или 10 млн. долларов США.

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

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

Рис. 2.1. Организационная структура

2.2 Основные характеристики информационной системы управления объектом

2.2.1 Функциональная структура системы

Рис. 2.2. Функциональная структура

2.2.2 Структура и характеристика видов обеспечения

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

На рисунке 2.1 показаны основные процессы, протекающие в информационной системе. Информационная сис­тема немыслима без персонала, взаимодействующего с компью­терами и телекоммуникациями. В этом смысле персонал — это неотъемлемый и, более того, основной элемент информационного менеджмента.

Рис. 2.3. Процессы в информационной системе

В качестве технологической среды информационной сис­темы можно рассматривать виды обеспечения, приведенные на рис. 2.2

Рис. 2.4. Обеспечения информационной системы (технологическая среда информационной системы)

3. Проектный раздел

3.1 Постановка задачи

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

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

         Утилита должна вызываться через пункт меню в программе Teamcenter (Tools -> Job report). Перед этим в Teamcenter должен быть выбран процесс для которого будет производиться генерация отчета.

         Добавление пункта меню должно производиться с помощью класса написанного на языке Java SE 1.4, а логика генерирования отчета на языке C++ как динамическая библиотека (dll).

3.1.1 Архитектура задачи

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

Рис. 3.1. Архитектура ПО

3.1.2 Описание метода решения задачи

Задача решается написанием динамичной библиотеки на языке C++, и класса для интерфейсной части TeamCenter на языке Java 1.4.

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

3.2 Информационное обеспечение подсистемы или задачи

3.3 Описание бизнес-процесса

Рис. 3.1. Бизнес-процесс разработки ПО

3.4 Программное обеспечение задачи

Для разработки модулей для системы Teamcenter требуется писать программы для С++ части в Visual Studio 6.0 – 2008, а “ява” части в с Eclipse v3.3.

4. Заключение

В данной работе были успешно решены поставленные задачи, было разработано ПО в соответствии указанному бизнес-процессу.

На данном этапе улучшения данной схемы не требуется.

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

1.                Гулин В.Н. Информационный менеджмент. – Москва, Современная школа, 2009

2.                Калаченцов В.Д., Кобко Л.И., Рыжко А.Л. Основы применения программного инструментария для создания систем информационного менеджмента. – Москва, МАИ 2006

3.                Костров А.В., Александров Д.В. Уроки информационного менеджмента. – Москва, Финансы и статистика 2005

4.                Крупский А.Ю., Феоктистова Л.А. Информационный менеджмент. – Москва, Дашков и Ко 2009

5.                Симионов Ю.Ф., Бормотов В.В.  Информационный менеджмент. – Москва, Феникс, 2006

Страницы: 1, 2, 3, 4