Методические указания для самостоятельной работы студентов Дата разработки 15. 07. 2008

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

«ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
»

В.Г. Ротарь, Л.И. Кравцова

ИНФОРМАЦИОННЫЙ менеджмент:

ОТВЕТЫ на вопросы ГОСударственного образовательного стандарта

Методические указания для самостоятельной работы студентов

Дата разработки 15.07.2008

Дата актуализации 15.12.2009

Томск 2009

©

Ротарь В.Г., Кравцова Л.И.

Информационный менеджмент: ответы на вопросы государственного стандарта. Часть 1. - Пособие для самостоятельной работы студентов. – Кафедра ОСУ АВТФ. – Томск: 2009. – с.

Учебное пособие содержит ответы на вопросы Государственного Образовательного Стандарта (ГОС) по дисциплине «Информационный менеджмент. Ответы на многие вопросы ГОС критичны ко времени, характиризующему уровень развития «Hard» и «Soft» компонентов информационных технологий и информационных систем. Настоящее пособие включает реферативный материал из доступных литературных источников, включая информационные ресурсы «Интернет». Рекомендуется студентам всех форм обучения для экспресс – знакомства с основами информационного менеджмента (INFMAN) как учебной дисциплиной, так и возможной сферой своей профессиональной деятельности в будущем.

Методические указания подготовлены на кафедре оптимизации систем управления ТПУ и предназначены для студентов, обучающихся по направления 010502 (351400) «Прикладная информатика в экономике».

СОДЕРЖАНИЕ

1..... Понятие информационного менеджмента. 5

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

2.1. Области деятельности ИТ-менеджера: 6

2.2. От теории к практике. 7

2.3. Гибкость интеграции – залог успеха. 8

3..... Соотношение информационной технологии и информационной системы.. 9

4. Распределение ИТ между лицами, принимающими решения в зависимости от типа управленческой структуры.. 10

5..... Параметры эффективного распределения ИТ в ЭИС.. 13

5.1. Понятие и классификация ЭИС.. 14

6..... Стратегическое планирование развития ИТ и ИС на объекте управления 17

6.1. Связь стратегии развития ИСУ и стратегии развития предприятия. 18

6.2. Варианты развития ИСУ.. 20

6.3. Выбор оптимального варианта развития ИСУ.. 22

6.4. Готовность предприятия к разработке стратегии развития ИСУ.. 23

7. Классификация ИС. Типы ИС: управленческие информационные системы, информационные системы поддержки принятия решений и информационные системы поддержки исполнения. 23

7.1. Классификация ИС по функциональному признаку. 25

7.2. Классификация ИС по характеру обработки информации. 27

8. Тенденция развития различных типов ИС и возможности их применения на объекте управления. 28

8.1. Средства производственной автоматизации. 29

8.2. Перспективные направления развития средств промышленной автоматизации. 33

9. Тенденция развития и возможности применения управленческих информационных систем на объекте управления. 35

9.1. Принципы классификации. 36

9.2. Категории систем: 38

9.3. Классы систем операционного управления. 39

10. Тенденция развития и возможности применения информационных систем поддержки принятия решений на объекте управления 42

10.1. Система поддержки принятия решений DSS. 42

10.2. Цели, назначение и практика систем класса DSS. 43

10.3. Предложения DSS-систем.. 47

11. Тенденция развития и возможности применения информационных систем поддержки исполнения решений на объекте управления. 49

11.1. Качество систем поддержки принятия решений. 49

11.2. Задачи систем поддержки принятия решений. 50

11.3 Решение типовых задач посредством SCADA- системы.. 53

12... Организация управления на базе управленческих ИС.. 55

13... Организация управления на базе ИС поддержки принятия решения. 55

14... Организация управления на базе ИС поддержки исполнения решений. 58

15. Оценка преимуществ и недостатков закупки готовых или разработки новых ИТ и ИС 59

16... Критерии оценки рынка ИТ и ИС.. 60

16.1. Критерии оценки вариантов развития ИСУ.. 60

17. Организация управления для различных этапов организации ИТ и ИС : разработка, внедрение, эксплуатация, развитие (модернизация) 62

17.1. Предпроектное обследование. 62

17.2. Эскизное, техническое – предварительное проектирование: 62

17.3. Рабочее - детальное проектирование: 62

17.4. Разработка информационной системы.. 62

17.5. Ввод информационной системы в эксплуатацию.. 63

17.6. Эксплуатация информационной системы.. 63

18. Состав и содержание работ на этапе разработки ИТ и ИС.. 63

18.1. Основные участники разработки. 63

18.2. Документирование этапов разработки. 64

18.3. Ответственность заказчика. 65

19... СОСТАВ И СОДЕРЖАНИЕ РАБОТ НА ЭТАПЕ ВНЕДРЕНИЯ ИТ И ИС.. 69

19.1. Особенности внедрения. 70

19.2. Подготовка к внедрению.. 72

19.3. Рабочая (промышленная) эксплуатация. 73

19.4. Сопровождение проекта. 74

1. Понятие информационного менеджмента
[1]

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

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

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

Итак, информация - важнейший аспект в бизнесе компании. Но сама по себе информация ничего не значит в процессах. Необходимо иметь также:

· потребность в использовании информации;

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

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

Информационный менеджмент

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

Информационный менеджмент включает следующие группы методов управления информацией:

· методы анализа и оценки информационных потребностей;

· методы сбора информации;

· методы накопления информации;

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

o управление процессом создания ИТ;

o управление техническими средствами;

o управление программными средствами;

o методы управления бизнес-объектами (новое направление информационного менеджмента);

o методы анализа информации.

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

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

Человек, который может видеть информационные решения, проектировать информационные технологии, управлять построением информационных систем получил уже устоявшееся определение – ИТ-менеджер. Такая узкая специализация менеджмента тоже обусловлена требованиями современного общества. Эволюционно, в российских организациях уже сейчас складываются позиции «узких» менеджеров. Это и финансовый директор, и исполнительный директор, и генеральный директор. Должности были несколько лет назад позаимствованы из структур зарубежных западных организаций. Но и за рубежом принципы управления развиваются. Так, недавно, практически в каждой крупной организации появилась позиция CIO (Chief Information Officer), по сути эквивалентная складывающейся в России позиции ИТ-менеджера. И специализация менеджеров достигла такой степени, что при общении с западным бизнесменом при употреблении слова «менеджер» необходимо уточнять, о каком именно менеджере идет речь. Возможно, через несколько лет произойдет очередная трансляция западного опыта и в российских компаниях появится должность информационного директора. На данный момент лишь некоторые прогрессивные организации включают ИТ-менеджера в состав правления организации.

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

2.1. Области деятельности ИТ-менеджера:
[2]

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

.

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

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

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

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

2.2. От теории к практике

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

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

На практике сегодня широко используются решения от различных производителей. Следует назвать продукты cемейства Lotus от IBM, которые предоставляют средства беспроводного доступа к электронной почте и другим ресурсам, а также поддерживают различные мобильные устройства - мобильные телефоны, смартфоны, PDA, пейджеры. Известна своими новациями в плане использования средств удаленного доступа в совместной работе и корпорация Microsoft. Это, в частности, решения, входящие в состав Exchange Server (Outlook Mobile Access, ActiveSync, Outlook Web Access), которые позволяют осуществлять безопасный доступ к корпоративным данным даже в условиях низкоскоростных каналов и держать связь с персоналом, находящимся далеко от офиса.

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

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

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

В качестве примера предлагаемых решений можно рассмотреть программный пакет Serena Team Track, который является средством автоматизации рабочих процессов ИТ-подразделений и позволяет осуществлять управление задачами на каждом этапе их выполнения - назначать ответственных исполнителей, приоритеты, проставлять статусы и отслеживать сроки выполнения. Это ПО легко интегрируется с продуктами Microsoft (Outlook), MS Project, IIS, а также предоставляет широкие возможности по расширению модели бизнес – процессов и технологии документооборота, имеет инструмент разработки TeamScript, основанный на известном продукте MS VBScript. Высокая масштабируемость данного продукта основана на возможности выбора одной из таких БД, как MS SQL, Oracle, MS Access.

Конечно, нельзя обойти вниманием решения от Microsoft. Это линейка продуктов, входящих в Microsoft Office, Microsoft Project, технологии Microsoft SharePoint и InfoPath. SharePoint создан для создания корпоративного внутреннего сайта, позволяющего осуществлять взаимодействие между службами предприятия, и включающего в себя средства контроля документооборота. InfoPath является эффективным средством сбора информации с широким выбором шаблонов и возможностью их расширения. Поддерживает любые пользовательские XML –схемы, что позволяет интегрировать собранную с помощью InfoPath информацию с различными Web-сервисами и бизнес-процессами. Большим преимуществом является то, что эти продукты предоставляют и широко используют уже привычную среду и инструментарий офисных приложений Microsoft, а так же используют для хранения и обмена информацией БД MS SQL Server, могут интегрироваться с другими источниками данных.

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

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

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

2.3. Гибкость интеграции – залог успеха

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

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

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

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

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

3. Соотношение информационной технологии и информационной системы
[3]

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

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

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

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

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

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

4. Распределение ИТ между лицами, принимающими решения в зависимости от типа управленческой структуры
[4]

Жизненный цикл развития ИСУ

Жизненный цикл развития информационной системы управления можно условно разделить на несколько этапов:

· подготовительный этап (разработка стратегии развития ИСУ);

· поток проектов (реализация программы развития);

· эксплуатация (применение стандартов эксплуатации и функционирования).

Подготовительный этап.
Модель стратегического планирования развития ИСУ можно представить с помощью следующих стадий и задач по ним:

· оценка бизнеса и используемых информационных технологий (анализ стратегии бизнеса, формализация бизнес-приоритетов и выявление ИТ-потенциала, оценка текущего ИТ-окружения);

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

· планирование внедрения стратегии (разработка стратегических проектов, подготовительная деятельность, анализ технологических особенностей).

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

Таблица 2.
Роли и ответственность при разработке стратегии развития ИСУ

	Совет директоров/ собственники	Генеральный управляющий	Финансовый директор	Руководители бизнес-направлений
Участие в разработке стратегии	Консультации по отрасли (аналоги, опыт, эксперты)	Обеспечение интересов всех бизнес-единиц (БЕ) и учета всех функций	Обеспечение «присутствия» всех БЕ	Приоритеты БЕ, услуги по поддержке бизнес-направлений
Вклад в разработку стратегии	Тенденции в отрасли, сценарии развития	Миссия и цели, выбор БЕ (рост, инвестиции)	Финансирование ИСУ, финансовые и бизнес-риски	Новые рынки, клиенты, продукты (2-4 года), процессы поддержки
Вопросы компетенции	Соответствие уровня финансирования	Адекватность потребностям организации	Возможности финансовой поддержки, смягчение рисков	Адекватность потребностям бизнес-единиц
Участие в реализации	Периодический обзор на соответствие бизнес-целям	Контроль соответствия стратегии бизнеса, разрешение конфликтов между БЕ	Финансовые гарантии, контроль рисков	Отслеживание изменений в стратегии БЕ и их учет в общей стратегии развития ИСУ

Поток проектов

Реализация программы развития ИСУ, утвержденной в рамках разработки стратегии, может быть описана с помощью итерационной концепции «Мероприятия — Готовность — Проекты — Цели» (рис. 2). В ней предполагается следующее:

процесс развития ИСУ должен быть непрерывным и итерационным;

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

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

проекты должны быть взаимосвязанными и взаимодополняющими;

управление проектами осуществляется по принципам мультипроектного управления (для достижения сбалансированности рамок проектов и используемых ресурсов).

Рис. 2.
Концепция развития ИСУ (в новом окне) >>

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

Проведение мероприятий позволяет:

сократить время реализации проектов;

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

максимизировать экономический эффект;

повысить качество результатов проекта;

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

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

избежать неразрешимых проблем и конфликтных ситуаций при реализации проектов;

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

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

формирование Наблюдательного совета по развитию ИСУ;

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

разработка и утверждение программы обучения Проектной группы;

расширение и оптимизация деятельности ИТ-отдела;

проведение аудита программного и аппаратного обеспечения в структурных единицах;

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

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

Таким образом достигается поступательное развитие ИСУ, которое, в свою очередь, будет учитывать изменяющиеся требования и согласовываться с процессом развития предприятия

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

5. Параметры эффективного распределения ИТ в ЭИС
[5]

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

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

Экономические информационные системы с момента появления первых электронно-вычислительных машин претерпели существенное изменение в своем развитии.

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

В 60-е годы возникает идея комплексной автоматизации управления предприятиями и интеграции информационного обеспечения на основе баз данных. Реальностью автоматизированные системы управления стали в 70-е годы на базе ЭВМ 3-го поколения, которые позволили создавать вычислительные системы с распределенной терминальной сетью. Однако недостаточное быстродействие и надежность вычислительных машин, отсутствие гибких средств реализации информационных потребностей пользователей не смогли превратить ЭИС в инструмент коренного повышения эффективности управления предприятиями.

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

Для 90-х годов характерно развитие телекоммуникационных средств, которое привело к созданию гибких локальных и глобальных вычислительных сетей, предопределивших возможность разработки и внедрения корпоративных ЭИС (КЭИС). КЭИС объединяют возможности систем комплексной автоматизации управления 70-х годов и локальной автоматизации 80 - годов. Наличие гибких средств связывания управленческих работников в процессе хозяйственной деятельности, возможность коллективной работы, как непосредственных исполнителей хозяйственных операций, так и менеджеров, принимающих управленческие решения, позволяют во многом пересмотреть принципы управления предприятиями или проводить кардинальный реинжиниринг бизнес-процессов.

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

5.1. Понятие и классификация ЭИС

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

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

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

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

* гомеостазиса, то есть обеспечения устойчивого функционирования

системы и достижения общей цели;

* адаптивности к изменениям внешней среды и управляемости посредством воздействия на элементы системы;

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

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

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

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

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

* планирование -
функция, определяющая цель функционирования экономической системы на различные периоды времени (стратегическое, тактическое, оперативное планирование);

* учет
- функция, отображающая состояние объекта управления в результате выполнения хозяйственных процессов;

* контроль
- функция, с помощью которой определяется отклонение учетных данных от плановых целей и нормативов;

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

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

ЭИС связывает объект и систему управления между собой и с внешней средой через информационные потоки:

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

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

ИП З
- информационный поток из системы управления на объект управления

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

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

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

К обработке информации в ЭИС предъявляются следующие требования:

* полнота и достаточность информации для реализации функций управления;

* своевременность предоставления информации;

* обеспечение необходимой степени достоверности информации в зависимости от уровня управления;

* экономичность обработки информации: затраты на обработку данных не должны превышать получаемый эффект;

* адаптивность к изменяющимся информационным потребностям пользователей.

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

* системы обработки данных (ЕDP - electronic data processing);

* информационной системы управления (МIS - management information system);

* системы поддержки принятия решений (DSS - decision support system).

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

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

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

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

Корпоративная (интегрированная) ЭИС
автоматизирует все функции управления на всех уровнях управления. Такая ЭИС является многопользовательской, функционирует в распределенной вычислительной сети.

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

Одним из основных свойств ЭИС является делимость на подсистемы, которая имеет ряд достоинств с точки зрения разработки и эксплуатации ЭИС, к которым относятся:

· Упрощение разработки и модернизации ЭИС в результате специализации групп проектировщиков по подсистемам;

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

· Упрощение эксплуатации ЭИС вследствие специализации работников предметной области.

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

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

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

6. Стратегическое планирование развития ИТ и ИС на объекте управления
[6]

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

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

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

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

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

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

6.1. Связь стратегии развития ИСУ и стратегии развития предприятия

Управление процессом развития предприятия может осуществляться в двух взаимосвязанных формах: стратегии
(«законодательная» составляющая изменений) и программ
— групп проектов или отдельных проектов (исполнительная составляющая).

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

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

В таблице 1 представлена логика связей этих составляющих.

Таблица 1.
Взаимосвязь стратегических направлений и программ

Стратегические направления/ Программы	Направление развития № 1	Направление развития № 2	Направление развития № 3	Направление развития № 4
Программа № 1	Проект № 1.1	Проект № 1.2	Проект № 1.3	Проект № 1.4
Программа № 2		Проект № 2.2		Проект № 2.4
Программа № 3	Проект № 3.1	Проект № 3.2	Проект № 3.3
Программа № 4			Проект № 4.3	Проект № 4.4

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

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

Стратегия развития ИСУ
должна давать ответ на четыре основных вопроса: «зачем?», «чего не хватает сейчас?», «как?» и «каковы ожидаемые результаты?». Остановимся на этих вопросах подробнее — это поможет понять суть стратегии развития ИСУ и ее взаимосвязь со стратегией развития предприятия в целом, или, другими словами, со стратегией бизнеса.

Зачем?
Ответом на вопрос должна служить непосредственно стратегия бизнеса с миссией, целями и задачами предприятия. Профессионально и комплексно разработанная стратегия бизнеса позволит определить место ИСУ и формализовать целевые показатели стратегии. Место ИСУ выражается в том, каким образом она способна повлиять на успешность и эффективность достижения целей в рамках стратегии бизнеса, а также в оценке этого влияния на развитие предприятия. Работы в области стратегии развития ИСУ, помимо вопросов управления, должны охватывать также такие области, как вопросы использования прикладных систем (программного обеспечения) и инфраструктурные вопросы.

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

Как?
Для ответа на этот вопрос необходимо формализовать требования к ресурсам, которые будут использоваться для развития и функционирования ИСУ, а также выбрать наиболее оптимальный вариант развития.

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

Каковы ожидаемые результаты?
Этот вопрос необходимо задавать с целью выявления и четкой формализации эффектов от развития ИСУ, допустимых затрат и рисков. Необходимо рассматривать управленческие, социальные и экономические эффекты в комплексе, разрабатывая при этом качественные и количественные показатели эффективности. Данные показатели должны быть взаимосвязаны с показателями, разработанными для стратегии бизнеса. В процессе разработки стратегии развития ИСУ должна быть заложена основа для оптимизации всех планируемых затрат, а также формализованы возможные риски для последующей разработки упреждающих мероприятий.

Формирование интереса к стратегии развития ИСУ происходит, как правило, при определенных условиях. Другими словами, могут существовать следующие основания для разработки
стратегии:

видение
(успешно проведена разработка собственной стратегии бизнеса; руководство начало рассматривать ИСУ как инструмент управления; есть успехи других компаний в ИТ-проектах);

финансовые средства
(ИТ-затраты становятся значимыми для бюджета; текущий уровень ИСУ становится тормозом развития бизнеса; планируются или уже сделаны крупные инвестиции в информатизацию);

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

Таким образом, основными базисами разработки
стратегии развития ИСУ следует считать:

отправную точку
— существующее положение (как в сфере управления и функционирования, так и в сфере использования ИТ);

желаемые горизонты
— стратегию бизнеса (стратегию развития предприятия);

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

Рис. 1.
Составные части стратегии развития ИСУ

Комплексное использование этих базисов дает возможность получить три составные части стратегии развития ИСУ (рис. 1):

позиционирование и роль ИТ
на предприятии (приоритеты и направления их развития), согласованные со стратегией бизнеса (т. е. учтено, на какие бизнес-процессы влияет функционирование ИСУ);

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

техническая архитектура
(аппаратные и программные платформы, общие службы и интеграция компонент, методологии и стандарты).

Самое главное в процессе разработки стратегии развития ИСУ — это достижение соответствия между прогнозируемым/желаемым уровнем развития бизнеса и необходимым для этого уровнем развития ИТ.

6.2. Варианты развития ИСУ

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

Варианты развития возникают в результате взаимоотношений между принципами управления (сегодняшними и желаемыми/прогнозируемыми) и средствами их поддержки (которые можно разделить на две группы — разработанное собственными силами и готовое управленческое ПО). Возможные укрупненные варианты развития ИСУ представлены на рис. 3. Перемещение относительно координаты «Принципы управления» является процессом перехода на новый уровень управления согласно стратегии бизнеса. В свою очередь, перемещение относительно координаты «Средства поддержки используемых принципов управления» является процессом выбора инструмента, с помощью которого будет осуществляться данный переход.

Рис. 3.
Варианты развития ИСУ

Дадим краткую характеристику возможных сценариев. Сначала опишем варианты для предприятия, которое использует «самописное» ПО (для отечественных предприятий данная ситуация является наиболее распространенной).

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

разработку и утверждение долгосрочной концепции ПО (архитектура, уровень интеграции задач, средства разработки, СУБД и пр.);

четкую постановку задачи для собственной команды разработчиков;

утверждение сроков и очередности разработки и внедрения ПО;

использование спиральной модели ЖЦ систем.

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

оптимизированы бизнес-процессы;

существует план перехода на новый уровень управления;

есть достаточное количество квалифицированных работников;

сформированы требования к ПО;

выбрана компания-поставщик, которая способна предоставить профессиональную команду внедрения;

выделен бюджет;

функционирует техническая инфраструктура ИСУ и многое другое.

К сожалению, для большинства отечественных предприятий данный вариант остается непригодным.

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

Вариант A-C-D.
Переход на использование готового управленческого ПО и поэтапное наращивание его функциональности с ростом уровня принципов управления.

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

Вариант A-C-D требует осуществления комплексного выбора управленческого ПО.

Вариант A-B-D.
Наращивание функциональности имеющегося управленческого ПО с планированием перехода на готовое управленческое ПО.

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

В рамках данного варианта внедрение готового ПО предполагает применение метода «параллельной стратегии», когда одновременно работают старая и новая система. Результаты их работы сравниваются — и если они согласуются длительное время, осуществляется переход на новую систему.

Теперь поговорим о предприятиях, которые работают на «готовых» системах.

Вариант C-D
аналогичен варианту А-В, но в качестве средств поддержки используется готовая система.

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

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

6.3. Выбор оптимального варианта развития ИСУ

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

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

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

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

платформы серверов и рабочих станций;

средства хранения данных;

локальные и распределенные сети;

применение Internet-технологий;

управление системами;

технологии и средства интеграции;

СУБД, хранилища данных и архитектура данных;

информационная безопасность и защита данных;

средства разработки приложений.

Организационные критерии.
Среди них наиболее существенными являются:

масштабы и рамки проведения бизнес-моделирования;

необходимость и сложность внедрения управленческих изменений;

потребность во внедрении методов управления проектами;

предполагаемое расширение штата и функций ИТ-отдела;

уровень привлечения сторонних организаций.

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

правильность выбора системы (управленческого ПО);

риск незавершенности проекта внедрения;

риски качества продуктов проекта;

риски выхода за рамки проекта и другие.

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

6.4. Готовность предприятия к разработке стратегии развития ИСУ

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

На предприятии можно выделить следующие группы факторов, влияющих на процесс перехода к новому уровню ИСУ:

наличие стратегии бизнеса
(и ее использование);

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

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

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

процессы жизненного цикла ИСУ2
(на предприятии существует база для реализации или уже реализуются необходимые процессы ЖЦ ИСУ — договорные, технические, корпоративные, проектные и адаптирующие);

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

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

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

7. Классификация ИС. Типы ИС: управленческие информационные системы, информационные системы поддержки принятия решений и информационные системы поддержки исполнения
[7]

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

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

Согласно общепринятой классификации ИС - информационные системы - подразделяются:

по масштабам применения - настольные и офисные

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

централизованные, децентрализованные и коллективного использования

с интеграцией по уровням управления, по уровням планирования и т.д.

по функциональному признаку – производственные, маркетинговые (анализа рынка, рекламные, снабженческие и т.п.), финансовые (бухгалтерские, статистические, и т.п.), кадровые;

по квалификации персонала и уровням управления – стратегические (топ-менеджеров), функциональные (менеджеров среднего звена) и оперативные (специалистов)

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

по оперативности обработки данных – пакетной обработки и оперативные

по степени автоматизации - ручные, автоматические, автоматизированные

по характеру использования информации - на информационно-поисковые, информационно-справочные, информационно-решающие, управляющие, советующие и т.п.;

по степени централизации обработки информации — на централизованные, децентрализованные, информационные системы коллективного использования

по характеру использования вычислительных ресурсов – на локальные и распределенные;

по сфере деятельности - на государственные, территориальные (региональные), отраслевые, объединений, предприятий или учреждений, технологических процессов

по классу реализуемых технологических операций - на системы с текстовыми редакторами, системы с табличными редакторами, СУБД, СУБЗ, системы с графикой, мультимедиа, гипертекстом

по месту в процессе управления предприятия – на АРМ специалиста, ИС руководителя, ИС внешнего контролера, интегрированные системы, объединяющие в себе часть или все из этих функций

по концепции построения – файловые, автоматизированные банки данных, банки знаний, ХД

по режиму работы - на пакетные, диалоговые и смешанные

7.1. Классификация ИС по функциональному признаку

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

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

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

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

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

Производственная

Связана с непосредственным выпуском продукции и направлена на создание и внедрение в производство научно-технических новшеств;

Маркетинговая

Включает в себя:

анализ рынка производителей и потребителей выпускаемой продукции, анализ продаж;

организацию рекламной кампании по продвижению продукции;

рациональную организацию материально-технического снабжения;

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

Кадровая

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

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

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

Подсистемы производственной ИС - информационной системы

конструкторской подготовки производства;

технологической подготовки производства;

управления материально-техническим снабжением;

управления производственным процессом;

компьютерного инжиниринга и т. д.

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

Функции информационных систем

Система маркетинга	Производственные системы	Финансовые и учетные системы	Система кадров (человеческих ресурсов)	Прочие системы, (например ИС руководства)
Исследование рынка и про гнозирование продаж	Планирование объемов работ и разработка календарных планов	Управление портфелем заказов	Анализ и прогнозирование потребности в трудовых ресурсах	Контроль за деятельностью фирмы
Управление продажами	Оперативный контроль и управление производством	Управление кредитной политикой	Ведение архивов записей о персонале	Выявление оперативных проблем
Рекомендации по производству новой продукции	Анализ работы оборудования	Разработка финансового плана	Анализ и планирование подготовки кадров	Анализ управленческих и стратегических ситуации
Анализ и установление цены	Участие в формировании заказов поставщикам	Финансовый анализ и прогнозирование	"	Обеспечение процесса выработки стратегических решений
Учет заказов	Управление запасами	Контроль бюджета
		Бухгалтерский учет и расчет зарплаты

7.2. Классификация ИС по характеру обработки информации

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

Системы обработки данных
- СОД

(EDP - Electronic Data Processing, СОД) предназначены для учета и оперативного регулирования хозяйственных операций, подготовки стандартных документов для внешней среды (счетов, накладных, платежных поручений, расчета заработной платы, статистической отчетности и т.п.). Такие системы наряду с функциями ввода, выборки, коррекции информации выполняют математические расчеты без применения методов оптимизации. Горизонт оперативного управления хозяйственными процессами составляет от одного до несколько дней и реализует регистрацию и обработку событий (оформление и мониторинг выполнения заказов, приход и расход материальных ценностей на складе, ведение табеля учета рабочего времени и т.д.). Эти задачи имеют итеративный, регулярный характер, выполняются непосредственными исполнителями хозяйственных процессов (рабочими, кладовщиками, администраторами и т.д.) и связаны с оформлением и пересылкой документов в соответствии с четко определенными алгоритмами. Результаты выполнения хозяйственных операций через экранные формы вводятся в базу данных.

Информационные
системы (ИС) управления - ИСУ

(MIS - Management Information System, ИСУ)
ориентированы на тактический уровень управления: среднесрочное планирование, анализ и организацию работ в течение нескольких недель (месяцев), например анализ и планирование поставок, сбыта, составление производственных программ. Для данного класса задач характерны регламентированность (периодическая повторяемость) формирования результатных документов и четко определенный алгоритм решения задач, например свод заказов для формирования производственной программы и определение потребности в комплектующих деталях и материалах на основе спецификации изделий. Решение подобных задач предназначено для руководителей различных служб предприятий (отделов материально-технического снабжения и сбыта, цехов и т.д.). Задачи решаются на основе накопленной базы оперативных данных.

Системы поддержки принятия решений
- СППР

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

Идеальной считается ИС, которая включает все три типа перечисленных ИС.

8. Тенденция развития различных типов ИС и возможности их применения на объекте управления
[8]

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

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

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

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

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

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

Финансово-управленческие системы.

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

8.1. Средства производственной автоматизации

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

Системы
SCADA

В сегодняшней интерпретации «нижний» класс задач в иерархии управления производством относят к системам типа SCADA (Supervisory Control and Data Acquisition). Этот тип систем принадлежат классу HMI (Human-Machine Interface), что означает «человеко-машинный интерфейс» в смысле обеспечения двусторонней связи «оператор — технологическое оборудование». Система класса MMI означает, что технический персонал может наблюдать за ходом технологического процесса и оказывать влияние на него, то есть MMI — это средство отображения и представления технологической информации. Системы подобного класса в СССР назывались АСУТП (Автоматизированные системы управления технологическими процессами).

MES
(Manufacturing Execution Systems)

MES - группа систем, образовавшаяся между MMI и системами управления производством ERP/MRP II. К системам MES принято относить приложения, выполняющие следующие функции:

управление ресурсами в рамках технологического процесса;

планирование и контроль последовательности операций технологического процесса;

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

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

техническое обслуживание производственного оборудования;

интеграция систем ERP и SCADA.

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

Системы

ERP/

MRP II

Системы ERP (Enterprise Resource Planning) ориентированы на предприятие в целом, a MRP (Manufacturing Resource Planning) — на его технологические подразделения. По традиционной отечественной терминологии, это задачи АСУП (Автоматизированные системы управления предприятием). В истории развития этого класса систем можно выделить четыре этапа.

Первый этап.

Начало практической реализации технологической базы информационных систем управления (ИСУ) стало возможным только с появлением компьютеров третьего поколения с такими базовыми элементами, как средства хранения информации большого объема с "прямым доступом" и средства интерактивного доступа к хранимой информации. Все это появилось в конце 60-х - начале 70-х гг., и связано было прежде всего с выходом на рынок системы IBM/360 и монитора CICS. В ИСУ первого поколения практически все программное обеспечение было создано на самих предприятиях. Программы были приспособлены к конкретном}' предприятию, либо к узкому кругу родственных компаний и требовали поддержки силами высококлассных программистов.

Второй этап.

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

В конце 70-х/начале 80-х гг. появились фирмы, специализирующиеся на разработке и внедрении ИСУ. К этому времени базовой моделью для ИСУ стало направление MRP (Material Resource Planning) - планирование материальных ресурсов. Следующим шагом стал стандарт MRP II, который, в отличие от предшествующей концепции MRP, включает также и планирование производственных мощностей. Основа концепции MPR заключается в следующих принципах:

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

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

полная инвентаризация всех видов ресурсов предприятия в "едином информационном пространстве";

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

базовые понятия обобщены и типизированы для любого предприятия (рабочие центры, запасы, центры затрат, маршруты, операции, планирование мощностей и т.п.);

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

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

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

Каждый производитель систем класса MRP использовал в основном собственные средства поддержки базы данных и собственные средства разработки приложений. Впоследствии некоторые начали использовать и появившиеся коммерческие иерархические и сетевые СУБД.

Третий этап.

В конце 80-х гг. начали появляться производители нового поколения MRP систем. Новые поставщики MRP/ERP систем начали использовать появившиеся на рынке коммерческие реляционные СУБД и ориентированные на SQL средства разработки. Это позволяло новым поставщикам, с одной стороны, не тратить ресурсы на собственные инструментальные средства, а с другой, оперативно отслеживать и использовать новейшие достижения ИТ. Пользователям при внедрении новых систем не требовалось дополнительно изучать новые инструментальные средства, отличные от стандартно поставляемых на рынок.

По мере внедрения систем MRP/ERP появилась возможность пересмотреть традиционные подходы к учету затрат и планированию, которые были основаны на "ручной " информационной технологии. Например, в подсистеме типа "Главный Планировщик" начали использовать "проигрывание" нескольких вариантов плана по сценарию "что-если", а в подсистеме учета затрат началось применение новых возможностей так называемого АВС метода (Activity Based Costing).

Четвертый этап.

К четвертому поколению ИСУ можно отнести системы, для которых характерно:

активное использование типовых процедур и функций, выполняемых на уровне СУБД;

использование средств CASE для поддержки "электронного проекта" на всех этапах жизненного цикла ERP системы;

применение стандартных средств графического пользовательского интерфейса (в том числе и Web);

выделение в подсистемы аналитических средств поддержки принятия решений и средств поддержки реинжиниринга (BPR) в процессе эксплуатации.

Последнее поколение ИСУ еще больше связано со "специализацией и кооперацией" и основано на использовании объектно-ориентированного подхода для описания производственного процесса.

Системы САПР

Отдельная группа ПО - системы САПР. Современные технологии САПР для предприятий представлены системами CAD/CAM/CAE (Computer Aided Design, Manufacturing, Engineering). Эти системы позволяют обойтись без «бумажной» документации, осуществляя прямую связь между процессами разработки изделия и его производства, что позволяет повысить качество продукции и сократить период разработки. САПР не входит непосредственно в систему управления производством, но является важным компонентом компьютерного интегрированного производства (КИП) и играет существенную роль в проектировании и подготовки производства, а на дальнейших этапах жизненного цикла (ЖЦ) изделия - в качестве элемента системы электронного документооборота.

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

Системы PDM возникли на стыке ПО класса MRP/ERP и CAD. Их функция -обеспечение поддержки всего жизненного цикла продукции от разработки (CAE/CAD) до маркетинга. Одни PDM-системы представляют собой самостоятельные программные продукты, другие реализованы в виде модулей в рамках созданных ранее ERP-систем. Системы PDM, находясь между условными входами и выходами корпорации, аккумулируют все циркулирующие внутри компании данные по продукции, осуществляют планирование процессов и пошаговый контроль. В отличие от баз данных, они интегрируют информацию любых форматов и типов, поступающую от различных источников, предоставляя ее пользователям уже в структурированном виде, причем структуризация привязана к особенностям современного промышленного производства.

Основные функциональные возможности систем PDM:

организация хранения данных и управление документами;

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

Управление хранением данных и документами

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

Управление потоками заданий и процессами

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

Управление структурой продукта

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

8.2. Перспективные направления развития средств промышленной автоматизации.

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

Связующее
программное обеспечение: архитектура CORBA

На сегодня результатом совместной работы ряда крупнейших фирм-производителей является архитектура CORBA (Common Object Request Broker Architecture) - это связующее ПО, «расположенное» между операционной системой и приложениями. Использование данного программного «слоя» облегчает процесс создания приложений, так как дает возможность разработчику абстрагироваться от особенностей аппаратного и системного ПО. Трудности реализации преодолеваются с помощью среды межобъектных запросов Object Request Broker (ORB). Используя ORB, клиент может легко вызывать сервис на объект-сервере, при этом аппаратно клиент и сервер могут быть как на одной машине, так и на разных и общаться между собой по сети. ORB перехватывает запрос и отвечает за его доставку, передачу параметров, вызов сервиса, а также за доставку результатов. Таким образом, ORB обеспечивает обмен информацией между приложениями на различных устройствах в неоднородной распределенной среде, создавая связную объектно-ориентированную систему.

Стандартизация
методов доступа: технология OPC

Современные решения в области стандартизации связаны прежде всего с фирмой Microsoft. Это в первую очередь технология OPC (Object Linking and Embedding for Process Control). Она представляет собой стандартный метод для доступа к периферийным устройствам, системам SCADA/MMI или другим промышленным приложениям, основанным на технологиях OLE, СОМ (Component Object Model) и DCOM (Distributed СОМ). OPC представлена набором стандартных объектов, методов и свойств, отвечающих требованиям промышленных приложений реального времени. Эти требования включают в себя синтаксис для доступа к объектам, эффективную передачу данных от оборудования к приложениям, способность клиента работать с несколькими серверами одновременно и поддержку конфигурации сервера. Программные пакеты на основе OPC легко интегрировать в бизнес-приложения, поддерживающие OLE. В первой версии OPC, вышедшей в 1995 г., основной упор был сделан на сбор данных. Последняя разработка Microsoft в этой области — Windows DNA (Windows Distributed Internet Applications Architecture). Эта архитектура также основана на объектно-ориентированной СОМ-технологии создания функциональных пользовательских компонентов.

Интеграция в виде "виртуального предприятия»:
CALS-технологии

На первом этапе CALS расшифровывалась как Computer Aided Logistic Support – компьютерная поддержка поставок. Предметом CALS являлась безбумажная технология взаимодействия между организациями заказывающими, производящими и эксплуатирующими военную технику, а также формат представления соответствующих данных. Доказав свою эффективность в сфере ВПК, CALS-технологии начали активно применяться в других отраслях экономики: промышленности, строительстве, транспорте.

В настоящий момент CALS трактуется как Continuous Acquisition and Life Cycle Support – непрерывная информационная поддержка жизненного цикла изделия или продукта. По своей сути сегодня CALS является глобальной стратегией повышения эффективности бизнес-процессов, выполняемых в ходе жизненного цикла продукта за счет информационной интеграции информации, порождаемой на всех этапах жизненного цикла. Средствами реализации данной стратегии являются CALS-технологии, в основе которых лежит набор интегрированных информационных моделей: жизненного цикла и выполняемых в его ходе бизнес-процессов, продукта, производственной и эксплуатационной среды. Возможность совместного использования информации обеспечивается применением компьютерных сетей и стандартизацией форматов данных.

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

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

Для предприятия в целом использование CALS-технологий повышает эффективность кооперации с другими предприятиями за счет построения своеобразного «виртуального предприятия».

Таблица 1. Различные концепции автоматизации и ЖЦ продукта.

Этапы жизненного цикла	Концепции автоматизации и управления
Маркетинг и изучение рынка			CALS
Проектирование и разработка продукции		ИАСУ
Планирование и разработка процессов
Закупка	АСУП
Производство
Упаковка и хранение
Реализация
Установка и ввод в эксплуатацию
Техническая помощь и обслуживание
Эксплуатация (потребление)
Утилизация

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

9. Тенденция развития и возможности применения управленческих информационных систем на объекте управления

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

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

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

При этом чаще всего используется классификация, предложенная консультантом компании «Делойт и Туш СНГ» И. Карпачевым
. В ней все системы разбиты на четыре класса: [9]
локальные (системы для малого бизнеса), финансово-управленческие, средние интегрированные и крупные интегрированные системы.

В зависимости от обобщенного типа предприятия (таких типов у Карпачева четыре — малые предприятия, торговые и дистрибуторские компании, средние производственные предприятия и многофункциональные холдинги) предлагается некая матрица применимости систем.

Такая классификация не лишена недостатков и в значительной степени является обобщенной — как в части классификации систем, так и в части классификации предприятий.

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

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

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

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

Для проведения классификации предлагаем использовать стандартные понятия, повсеместно используемые для проведения классификации любых объектов и явлений: «Категория» - «Класс» - «Вид» - «Тип»

9.1. Принципы классификации

Категории систем по иерархии уровней управления

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

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

Горизонт стратегического планирования
обычно равен периоду от трех до пяти лет с разбивкой по годам (первый год иногда детализируется по кварталам). Этот план устанавливает главные задачи предприятия и цели, которые оно хочет достичь в указанный период. Основой стратегического плана служат долгосрочные прогнозы, которые учитывают самые разные аспекты — маркетинговые, финансовые, производственные, технологические.

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

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

какое количество рабочих понадобится для производства продукции (услуг);

в какой момент в них возникнет потребность;

придется ли работать сверхурочно или вводить вторую смену;

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

следует ли создавать запасы готовой продукции.

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

Оперативное управление
— это текущее (ежедневное или в рамках недели) управление и планирование. Оно дает ответы на конкретные вопросы, например «какую работу нужно выполнить сегодня или в течение текущей недели?», «кто именно будет отвечать за выполнение этой задачи?», «какую работу следует выполнить в первую очередь?».

Управление реального времени
— название говорит само за себя, это управление в режиме минут и секунд.

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

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

системы стратегического управления;

системы среднесрочного управления;

системы операционного управления;

системы оперативного управления;

системы управления в реальном времени.

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

Классы систем по управленческому циклу

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

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

Если мы хотим управлять эффективно, то должны реализовывать все функции управленческого цикла. Другой вопрос — как именно мы будем его осуществлять: планировать, организовывать, учитывать, контролировать и анализировать с помощью одной системы или планировать в Excel, учитывать в 1С, контролировать и анализировать опять в Excel или каким-то другим способом.

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

Виды систем

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

Авторы выражают надежды, что все участники рынка — консультанты, эксперты, клиенты, р

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

Типы систем

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

9.2. Категории систем:

-«Системы стратегического управления»

Системы данной категории обеспечивают поддержку функций управления на стратегическом уровне (в большей части — анализ, планирование и контроль). Примерами информационных систем стратегического управления являются системы CORPORATE PLANNER, Project Expert, системы Balanced Scorecard различных производителей и др. Разбиение систем данной категории на классы осуществляется в зависимости от глубины реализации в системах указанных функций управления: анализа, планирования,контроля. Фактические данные (данные учета) в эти системы вносятся либо вручную, либо путем импорта из систем оперативного учета в обобщенном виде.

- «Системы среднесрочного управления»

Системы данной категории еще называются системами управления эффективностью бизнеса (BPM — Business Performance Management, или Corporate Performance Management). К ним относятся как специализированные системы бюджетного планирования, контроля и управления по отклонениям (такие как Hyperion Pillar, Adaytum, Comshare MPC, Oracle Financial Analyzer, SyteLine Budgeting), так и инструменты класса «Инталев-бюджетирование». Аналогично категории стратегического управления разбиение систем данной категории на классы осуществляется в зависимости от полноты реализации в этих системах функций управления: анализа, планирования, организации выполнения, учета и контроля.

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

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

- «Системы управления реального времени»

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

- «Системы операционного управления»

Это категория систем, предназначенных поддерживать операционное и оперативное управление предприятием. К ним относится большинство представленных на рынке России информационных систем — как западных разработок (SAP R/3, Oracle Applications, BAAN, SyteLine ERP, MFG PRO, IRenaissance, IFS и др.), так и систем отечественных («Галактика», «Парус» и др.) и украинских разработчиков («ИТ-Предприятие», BS Intergator, «Программные системы развития» и др.). Сюда же относятся программы бухгалтерского учета (1С и т. д.). Именно с классификацией этих систем и выбором из их числа системы, наилучшим образом удовлетворяющей бизнес-требованиям, у предприятия и возникают самые серьезные сложности. Поэтому далее изложим принципы, позволяющие провести классификацию систем этой категории.

9.3. Классы систем операционного управления

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

Но это еще не все.

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

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

Для решения задачи классификации все поле управления предприятием, образованное функциональными областями управления, следует разбить на функции управления: анализ, планирование, организация выполнения, учета и контроля (рис. 3).

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

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

- бухгалтерского учета,

- управленческого учета,

- планирования и управления ресурсами предприятия (ERP-системы).

Кроме этих базовых классов можно выделить еще один класс — узкоспециализированных систем (примером могут служить системы MES — производственные исполнительные системы или ЕАМ — системы управления основными фондами предприятия).

«Бухгалтерские системы»

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

«Системы управленческого учета»

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

«Системы планирования и управления ресурсами или ERP-системы»

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

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

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

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

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

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

10. Тенденция развития и возможности применения информационных систем поддержки принятия решений на объекте управления
[10]

10.1. Система поддержки принятия решений
DSS

Так что же такое система поддержки принятия решений

(Decision Support Systems — DSS)?

Можно найти следующее ее определение: [11]

Decision Support Systems (DSS) является классом компьютеризированных информационных систем, которые поддерживают деятельность по принятию решений.

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

Дэниель Пауэр (Daniel Power) в 2002 году идентифицировал пять типов DSS-систем как систем, оперирующих связями, данными, документами, знаниями и моделями.

Вот его определение: [12]

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

Это уже, по крайней мере, конструктивно, хотя под данное определение попадают опять очень многие классы систем: ERP, GIS, DocFlow, Business Modeller, SCADA/ DCE, Project Management и др.

А вот еще одно определение:[13]

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

Это определение, безусловно, сужает область идентификации.

И наконец, еще одно:[14]

DSS-система помогает менеджеру или лицу, принимающему решение, использовать и манипулировать данными, использовать проверки и эвристики, а также строить и использовать математические модели.

В данном определении ссылка на «математические модели» — наиболее сильное место, но это противоречит высказанному ранее требованию легкости формирования языка запросов.

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

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

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

Мало чему помогает в смысле той же идентификации.

Инструментальные средства бизнес-интеллекта

Существует связное понятие — Business Intelligence Tools (инструментальные средства бизнес-интеллекта) — программное обеспечение, которое дает возможность пользователям наблюдать и использовать большие объемы сложных данных.

Выделяют три типа таких инструментальных средств: [15]

Средства многомерного анализа — также известные как OLАР (On-Line Analytical Processing) — программное обеспечение, которое дает пользователю возможность наблюдать данные в различных измерениях, направлениях или сечениях.

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

Инструментальные средства поиска данных (Data Mining Tools) — программное обеспечение, которое осуществляет автоматический поиск важных образцов (моделей), или зависимостей в данных.

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

10.2. Цели, назначение и практика систем класса DSS

Что можно считать предметом для систем класса DSS? В качестве такого предмета на основании анализа уже сложившейся практики можно назвать:

финансовый анализ и прогнозирование;

маркетинг реализации и закупок;

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

анализ рисков;

управление активами.

Каким образом данные задачи соотносятся с общей задачей информационного обслуживания бизнеса? К информационному обслуживанию бизнеса можно отнести:

увязку стратегических задач бизнеса и ИТ;

распределение и контроль прикладного программного обеспечения;

оперативную поддержку пользователей; а также управление:

проектами;

производственными мощностями;

изменениями;

проблемами;

издержками;

непредвиденными ситуациями;

вспомогательными службами;

взаимоотношениями с клиентами;

взаимоотношениями с поставщиками.

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

людьми;

процессами;

стратегиями;

технологиями.

Как можно видеть, в сферу приложения систем DSS попадает почти половина структурных задач, возлагаемых на ИТ-службы. Это находит подтверждение при анализе рынка прикладных информационных систем. Так, мировой рынок, например, ERP-систем оценивается в настоящее время оборотами порядка 25 млрд. долларов. Рынок DSS-cистем, который возник только в середине 90-х годов, сейчас оценивается суммой порядка 10 млрд. долларов и растет существенно большими темпами, чем рынок корпоративных систем управления. Его рост порядка 30% в год против 10-15% роста ERP-рынка, и можно предположить, что в течение ближайших пяти лет можно ожидать достижения паритета. С другой стороны, если рынок систем DSS в настоящее время в основном связан с финансовым сектором, крупноформатной торговлей и телекоммуникациями, то можно ожидать постепенной ассимиляции функциональных возможностей DSS-систем в существующие системы ERP-класса, что, по-видимому, приведет к оживлению процессов обновления версий ERP-систем в корпоративном секторе.

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

Рассматривая деятельность корпораций в конкурентном окружении, Майкл Портер, например, выделяет следующую шестифакторную модель (см. рис.).

Диаграмма сравнительной конкурентоспособности по Майклу Портеру

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

Крупноформатная торговля и компании электронной коммерции

Крупноформатная торговля и компании электронной коммерции (B2C, B2B) явились первыми институциональными заказчиками на DSS-системы. Основными задачами, решаемыми в данном секторе, являются:

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

распределение площадей, раскладка;

анализ эффективности деятельности менеджеров и мотивация персонала;

планирование и анализ эффективности рекламы, акций, распродаж и т.п.;

управление ценообразованием.

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

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

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

Банки и финансовые компании

Рынок DSS-систем в финансовых институтах сейчас самый емкий. Сфера применения DSS-систем в банках касается прежде всего:

банковского ритейла (платежные пластиковые карты и чеки);

анализа рисков;

предотвращения мошенничества (прежде всего с пластиковыми картами);

анализа потребительского поведения и проектирования новых финансовых услуг.

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

Предотвращение мошенничества — это перспективная зона использования методов искусственного интеллекта, которая никогда не будет исчерпана, как никогда не будет исчерпано воображение у мошенников.

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

Телекоммуникационные компании

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

Применение в промышленности

В промышленности к сферам применения можно отнести:

управление взаимоотношениями с клиентами;

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

финансовое и бюджетное планирование и управление;

анализ и управление рисками.

Какие изменения в парадигме управления промышленностью произошли за последние 50 лет? До 60-х годов промышленное производство развивалось главным образом за счет развития технологии, что выражалось тезисом: «производить и продавать». В тот период, безусловно, предложение явно формировало спрос. При этом основные производственные фонды были преимущественно материальными: здания, сооружения, оборудование, за которым стояли патентованные технологии.

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

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

Каковы сегодня основные промышленные тенденции? Это:

глобализация;

укрупнение;

специализация (для средних компаний);

интеграция в поставочные сети;

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

необходимость одновременно конкурировать как по качеству, так и по цене.

Анализируя причины отставания США в промышленном развитии, Комиссия Министерства внешней торговли США считает, что для подъема конкурентоспособности, в частности, необходимо (автор приводит только те пункты рекомендаций, которые имеют отношение к предмету рассмотрения, сам исходный перечень немного шире):

уделять больше внимания стратегическому планированию и больше инвестировать в исследования и разработки;

изучать стратегию иностранных конкурентов и совершенствовать собственную;

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

устранить коммуникативные барьеры в пределах организации;

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

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

«уделять … внимание стратегическому планированию…» — анализировать исторические данные по структуре себестоимости, динамике цен;

«изучать стратегию иностранных конкурентов» — анализировать динамику рынков;

«уделять больше внимания производственной функции» — анализировать затраты по управлению активами, динамику тарифов, эффективность использования оборудования и фондоотдачу;

«устранить коммуникативные барьеры» — анализировать исторические данные по параметрам реализации внутренних бизнес-процессов и эффективность результатов;

«признать ценность развития информационных связей» — анализировать исторические данные взаимоотношений с клиентами и поставщиками.

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

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

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

Рассматривая корпоративный рынок, очень показательным является анализ того, что могут и чего не могут наследуемые системы, прежде всего типов ERP и Project Management.

В государственном строительстве

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

10.3. Предложения DSS-систем

Обобщенный портрет DSS-систем можно составить на основе краткого анализа предложений компаний Cognos, SAS, Hyperion, Oracle. Так как данная статья носит вводный характер, автор не ставил перед собой целью сравнительный анализ продуктов — это тема других работ.

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

В основной функциональный набор

DSS-систем входят:

финансовое планирование и бюджетирование;

формирование консолидированной отчетности (до 200 преднастроенных отчетов);

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

(Balance Scorecards) с преднастроенными библиотеками показателей (до 500);

анализ взаимоотношений с клиентами и поставщиками;

анализ рыночных тенденций;

функционально-стоимостный анализ (ABC-Costing);

функционально-стоимостное управление (Activity Based Management, ABM);

система постоянных улучшений (Kiezen Costing);

многомерный анализ данных (OLAP);

выявление скрытых закономерностей (Data Mining);

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

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

событийное управление бизнесом (Event-driven BI);

анализ рисков;

формирование преднастроенных запросов (до 500-600);

интеллектуальный поиск (по неполным данным и неформальным запросам);

бизнес-моделирование и анализ эффективности выполнения бизнес-процессов;

референтные отраслевые модели.

Количество преднастроенных областей анализа достигает 30-40.

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

уведомления об определенном состоянии;

исполнение;

операционные события.

Информационной платформой являются хранилища данных

(Data Warehouse).

Инструментальная среда — интеграционные системы, основанные на открытых стандартах. Эти системы соответствуют требованиям:

информационной безопасности;

масштабируемости;

открытости;

многомерного и многовариантного представления данных;

интеллектуального интерфейса;

интегрируемости с основными платформами и бизнес-приложениями, интеграция данных из разнообразных источников, сетевая интеграция (прежде всего web);

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

Отличительной особенностью рассматриваемых продуктов является значительная большая, чем в случае с ERP-системами, готовность к немедленной работе (значительно меньшие циклы внедрения при наличии наследуемых баз данных).

Целевые результаты

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

здоров ли бизнес?

кто мой лучший клиент?

какой мой лучший продукт или услуга?

какого поставщика мне выгодно выбрать и почему?

где мы типично не укладываемся в сроки и почему?

какова эффективность деятельности нашего персонала?

какая дочерняя компания внесла наибольший (наименьший) вклад в результат?

что показывает анализ фондоотдачи оборудования?

какой сценарий и подход выбрать при слиянии (реструктуризации) компаний?

Аналитические методы в средствах разведки данных (Data Mining)

Аналитические методы дают конечному пользователю возможность осуществить весь цикл работы с исходными данными, имеющими большие объемы и невыясненную статистическую структуру. Этот цикл называется разведкой данных (Data Mining) и состоит из нескольких этапов: выборка, исследование, модификация, моделирование, оценка результатов

(Sample, Explore, Modify, Model, Assess).

Средства Data Mining дают возможность ставить и решать как традиционные, так и нетрадиционные задачи анализа. Например, традиционной является постановка задачи: «Определить, имеется ли статистическая связь между такими показателями, как объем производства товара и объем его реализации (продажи)».

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

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

В начале пути

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

11. Тенденция развития и возможности применения информационных систем поддержки исполнения решений на объекте управления
[16]

11.1. Качество систем поддержки принятия решений

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

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

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

· среднее время выработки решения (быстрота реакции);

· частота ошибочных решений (вероятность принятия неправильного решения);

· средние затраты на выработку решения;

· ущерб от необоснованных решений за определенный период;

· скорость обнаружения ошибок в принимаемых решениях.

Если при оценке целесообразности внедрения СППР опираться только на анализ прибыли на инвестируемый в автоматизацию капитал, то исказится или пропадет весь смысл совершенствования управленческих процессов. Цена достижения (вследствие совершенствования параметров процесса принятия решений) таких целей, как повышение качества обслуживания заказчиков, рост конкурентоспособности, не поддается точному денежному измерению.

Выделяются 5 основных задач
, решаемых при построении системы принятия решений: 1) найти данные; 2) собрать; 3) интегрировать; 4) расставить приоритеты (разбить на стадии); 5) представить в виде отчетов и прогнозов.

11.2. Задачи систем поддержки принятия решений

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

В результате необходимости упростить задачу поиска решения появился целый класс программных систем, призванных облегчить работу по анализу данных. Такие системы принято называть системами поддержки принятия решений – СППР (DSS, Decision Support Systems).

Можно выделить три основные задачи, решаемые в СППР:

ввод данных;

хранение данных;

анализ данных.

Существующие информационные системы, построенные как системы управления базами данных (СУБД) достаточно успешно решают задачи ввода (сбора) информации в систему, хранения и поиска информации и частично - анализа.

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

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

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

Информационно-поисковый. Система осуществляется поиск необходимых данных в соответствии с заранее определенными запросами. Этот класс задач решается построением систем информационно-поискового анализа на базе реляционных СУБД и статических запросов с использованием языка SQL.

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

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

Концепция хранилища данных

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

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

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

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

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

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

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

Таким образом, данные определенным образом подготовленные и собранные в ХД могут использоваться для анализа и принятия на их основе решений.

За формирование аналитических запросов к данным и представления результатов их выполнения в СППР отвечают подсистемы анализа (OLAP, Data Mining).

Упрощенным вариантом Хранилища данных является Витрина данных (ВД).

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

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

Технологии оперативной аналитической обработки данных - OLAP

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

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

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

С концепцией многомерного анализа данных тесно связывают оперативный анализ, который выполняют средствами OLAP-систем.

OLAP (On-Line Analytical Processing)- технология оперативной аналитической обработки данных, использующая методы и средства для сбора, хранения и анализа многомерных данных в целях поддержки процессов принятия решений.

Основное назначение OLAP-систем – поддержка аналитической деятельности, произвольных запросов пользователей-аналитиков. Цель OLAP-анализа – проверка возникающих гипотез.

Специальные технологии «добычи данных» - Data Mining[17]

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

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

Для обнаружения «скрытых» знаний применяется специальные методы автоматического анализа - Добыча Данных (Data Mining) (ДД).

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

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

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

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

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

проверка построенных моделей; что дает судить об адекватности построенной модели.

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

Этим этапом и завершается цикл ДД в строгом смысле слова.

11.3Решение типовых задач посредством SCADA
[18]
- системы

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

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

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

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

Концепция систем поддержки принятия и исполнения решений

Актуальной задачей при построении автоматизированных систем реального времени является перенос функций диспетчера по анализу данных, прогнозированию ситуаций и принятию соответствующих решений на компоненты интеллектуальных систем поддержки принятия и исполнения решений (СППИР). Концепция систем поддержки принятия и исполнения решений включает целый ряд средств, объединенных общей целью - способствовать принятию и реализации рациональных и эффективных управленческих решений. СППИР - это диалоговая автоматизированная система, выступающая в качестве интеллектуального посредника, поддерживающего естественно-языковый интерфейс пользователя со SCADA-системой, использующая правила принятия решений и соответствующие модели с базами знаний. Она организует удобный диалог SCADA-системы с пользователем, “ведет” его по этапам анализа информации, распознавания и прогнозирования ситуаций, анализирует параметры технологического процесса, помогает выбрать наилучшие решения в зависимости от возникшей ситуации, реализует их путем выдачи управляющих воздействий, корректируя тем самым ход технологического процесса и оптимизируя его параметры по заданному критерию.

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

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

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

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

Предлагаемая авторами концепция предполагает не просто создание обособленной экспертной системы обработки данных протекания технологического процесса, а интеграцию интеллектуальной СППИР с АСУ ТП на базе SCADA-системы Trace Mode, что существенно расширяет ее возможности, позволяет получить новый эффект от ее использования и удовлетворить возрастающие запросы разработчиков систем управления.

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

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

12. Организация управления на базе управленческих ИС

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

- инфраструктуру базовых сетевых служб в однородных и гетерогенных корпоративных сетях, создаваемых на основе операционных систем Microsoft Windows NT/2000 Server и Novell Netware;

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

- системы обеспечения безопасности корпоративных сетей на различных уровнях;

- корпоративные почтовые системы на основе Microsoft Exchange Server;

- бизнес-приложения на основе Microsoft SQL Server в области организации хранилищ данных, архивов документов, систем делопроизводства и документооборота.

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

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

13. Организация управления на базе ИС поддержки принятия решения

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

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

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

"… с момента появления первых разработок по созданию СППР, не было дано четкого определения СППР…".

Ранние определения СППР (в начале 70-х годов прошлого века) отражали следующие три момента: (1) возможность оперировать с неструктурированными или слабоструктурированными задачами, в отличие от задач, с которыми имеет дело исследование операций; (2) интерактивные автоматизированные (т.е. реализованные на базе компьютера) системы; (3) разделение данных и моделей. Приведем определения СППР: СППР - совокупность процедур по обработке данных и суждений, помогающих руководителю в принятии решений, основанная на использовании моделей

СППР - это интерактивные автоматизированные системы, помогающие лицу, принимающему решения, использовать данные и модели для решения слабоструктуризированных проблем

СППР - это система, которая обеспечивает пользователям доступ к данным и/или моделям, так что они могут принимать лучшие решения.

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

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

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

Согласно Turban , СППР обладает следующими четырьмя основными характеристиками:

1) СППР использует и данные, и модели;

2) СППР предназначены для помощи менеджерам в принятии решений для слабоструктурированных и неструктурированных задач;

3) Они поддерживают, а не заменяют, выработку решений менеджерами;

4) Цель СППР – улучшение эффективности решений.

Turban [26] предложил список характеристик идеальной СППР (которая имеет мало общих элементов с определением, приведенным выше):

Идеальная СППР:

(1) оперирует со слабоструктурированными решениями;

(2) предназначена для ЛПР различного уровня;

(3) может быть адаптирована для группового и индивидуального использования;

(4) поддерживает как взаимозависимые, так и последовательные решения;

(5) поддерживает 3 фазы процесса решения: интеллектуальную часть, проектирование и выбор;

(6) поддерживает разнообразные стили и методы решения, что может быть полезно при решении задачи группой ЛПР;

(7) является гибкой и адаптируется к изменениям как организации, так и ее окружения;

(8) проста в использовании и модификации;

(9) улучшает эффективность процесса принятия решений;

(10) позволяет человеку управлять процессом принятия решений с помощью компьютера, а не наоборот;

(11) поддерживает эволюционное использование и легко адаптируется к изменяющимся требованиям;

(12) может быть легко построена, если может быть сформулирована логика конструкции СППР;

(13) поддерживает моделирование;

(14) позволяет использовать знания.

Рассмотрим кратко историю создания СППР.

[править] История создания СППР

Классификации СППР

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

На уровне пользователя Haettenschwiler (1999) [12] делит СППР на пассивные, активные и кооперативные СППР. Пассивной СППР называется система, которая помогает процессу принятия решения, но не может вынести предложение, какое решение принять. Активная СППР может сделать предложение, какое решение следует выбрать. Кооперативная позволяет ЛПР изменять, пополнять или улучшать решения, предлагаемые системой, посылая затем эти изменения в систему для проверки. Система изменяет, пополняет или улучшает эти решения и посылает их опять пользователю. Процесс продолжается до получения согласованного решения.

На концептуальном уровне Power (2003) [21] отличает СППР, управляемые сообщениями (Communication-Driven DSS), СППР, управляемые данными (Data-Driven DSS), СППР, управляемые документами (Document-Driven DSS), СППР, управляемые знаниями (Knowledge-Driven DSS) и СППР, управляемые моделями (Model-Driven DSS). СППР, управляемые моделями, характеризуются в основном доступ и манипуляции с математическими моделями (статистическими, финансовыми, оптимизационными, имитационными). Отметим, что некоторые OLAP-системы, позволяющие осуществлять сложный анализ данных, могут быть отнесены к гибридным СППР, которые обеспечивают моделирование, поиск и обработку данных.

Управляемая сообщениями (Communication-Driven DSS) (ранее групповая СППР - GDSS) СППР поддерживает группу пользователей, работающих над выполнением общей задачи.

СППР, управляемые данными (Data-Driven DSS) или СППР, ориентированные на работу с данными (Data-oriented DSS) в основном ориентируются на доступ и манипуляции с данными. СППР, управляемые документами (Document-Driven DSS), управляют, осуществляют поиск и манипулируют неструктурированной информацией, заданной в различных форматах. Наконец, СППР, управляемые знаниями (Knowledge-Driven DSS) обеспечивают решение задач в виде фактов, правил, процедур.

На техническом уровне Power (1997) различает СППР всего предприятия и настольную СППР. СППР всего предприятия подключена к большим хранилищам информации и обслуживает многих менеджеров предприятия. Настольная СППР – это малая система, обслуживающая лишь один компьютер пользователя. Существуют и другие классификации (Alter , Holsapple и Whinston , Golden, Hevner и Power ). Отметим лишь, что превосходная для своего времени классификация Alter‘a, которая разбивала все СППР на 7 классов, в настоящее время несколько устарела.

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

• отчеты, как правило, базируются на стандартных для организации запросах; число последних относительно невелико;

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

• как правило, ИСР ориентированы на конкретный вертикальный рынок, например финансы, маркетинг, управление ресурсами.

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

При создании СППР можно использовать Web-технологии. В настоящее время СППР на основе Web-технологий для ряда компаний являются синонимами СППР предприятия.

Архитектура СППР представляется разными авторами по-разному. Приведем пример. Marakas (1999) [18] предложил обобщенную архитектуру, состоящую из 5 различных частей: (a) система управления данными (the data management system - DBMS), (b) система управления моделями (the model management system – MBMS), (c) машина знаний (the knowledge engine (KE)), (d) интерфейс пользователя (the user interface) и (e) пользователи (the user(s)).

14. Организация управления на базе ИС поддержки исполнения решений

Классические ERP-системы, в отличие от так называемого «коробочного» программного обеспечения, относятся к категории «тяжелых» программных продуктов, требующих достаточно длительной настройки, для того чтобы начать ими пользоваться. Выбор КИС, приобретение и внедрение, как правило, требуют тщательного планирования в рамках длительного проекта с участием партнерской компании — поставщика или консультанта. Поскольку КИС строятся по модульному принципу, заказчик часто (по крайней мере, на ранней стадии таких проектов) приобретает не полный спектр модулей, а ограниченный их комплект. В ходе внедрения проектная команда, как правило, в течение нескольких месяцев осуществляет настройку поставляемых модулей.

Достоинства

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

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

Недостатки

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

Ограничения и заблуждения:

Небольшие компании не могут позволить себе инвестировать достаточно денег в ERP и адекватно обучить всех сотрудников.

Внедрение может оказаться очень дорогим.

Иногда ERP сложно или невозможно адаптировать под документооборот компании и ее специфические бизнес-процессы.

Система может страдать от проблемы «слабого звена» — эффективность всей системы может быть нарушена одним департаментом или партнёром.

Сопротивление департаментов в предоставлении конфиденциальной информации уменьшает эффективность системы.

Проблема совместимости с прежними системами.

15. Оценка преимуществ и недостатков закупки готовых или разработки новых ИТ и ИС
[19]

Все эти системы относятся к классу MRPII/ERP и являются лидерами на международном и, в частности, российском рынке.

R3 от
SAP AG

На сегодняшний день компания SAP лидирует среди независимых производителей бизнес-приложений и занимает 36% этого рынка ПО. В России инсталлировано более 100 SAP систем, на локализацию систем R2 и R3 компания затратила более 6 млн. немецких марок.

Описание системы:

Основные модули:

финансовая бухгалтерия

контроллинг

управление материальными потоками

техническое обслуживание и ремонт оборудования

продажа, отгрузка, фактурирование

система проектов

управление, планирование и контроль основных средств

управление персоналом.

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

Oracle Applications от
Oracle

Представляет собой набор из более чем 35 интегрированных приложений, в которые входят:

приложения для управления финансами

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

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

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

приложения для управления персоналом

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

Данные программные модули для автоматизации всех аспектов деятельности предприятия.

BAAN

IV от

BAAN

Базовая система BAAN IV создана для комплексной поддержки системы управления предприятием. Все подсистемы конфигурируются под конкретные процедуры и задачи управления. Самое главное в системе – ее гибкость и функциональное наполнение.

Состав базовой системы BAAN IV.

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

производство

сбыт, снабжение, склады

сервис

финансы

транспорт

проект

организатор

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

Программно обеспечение BAAN может применяться в широком диапазоне предприятий – от средних до самых крупных.

Система управления БОСС компании АйТи.

Функциональные возможности комплексной интегрированной системы управления БОСС охватывают все основные бизнес процессы организации:

управление и бухгалтерский учет

финансовый менеджмент

управление персоналом

логистика

маркетинг и продажи

управление производством

делопроизводство и документооборот.

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

БОСС-КОРПОРАЦИЯ – полномасштабная система управления финансово-хозяйственной деятельностью, разработанная для крупных корпораций и торговых объединений. Состоит из четырех взаимодействующих подсистем (финансы, логистика, маркетинг и персонал).

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

16. Критерии оценки рынка ИТ и ИС

Критерий и технологии их выбора

.

16.1. Критерии оценки вариантов развития ИСУ

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

16.1.1. Возможности компании

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

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

16.1.2. Технические критерии

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

платформы серверов и рабочих станций;
средства хранения данных;
локальные и распределенные сети;
применение Internet-технологий;
управление системами;
технологии и средства интеграции;
СУБД, хранилища данных и архитектура данных;
информационная безопасность и защита данных;
средства разработки приложений.

16.1.3. Организационные критерии

Среди них наиболее существенными являются:

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

16.1.4. Риски

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

правильность выбора системы (управленческого ПО);
риск незавершенности проекта внедрения;
риски качества продуктов проекта;
риски выхода за рамки проекта и другие.

Анализ вариантов развития по оставшимся группам критериев (

16.1.5. Временные рамки

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

16.1.6. Бюджетные рамки

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

17. Организация управления для различных этапов организации ИТ и ИС : разработка, внедрение, эксплуатация, развитие (модернизация)

В жизненном цикле выделяют следующие стадии [1]:

17.1. Предпроектное обследование

Сбор материалов для проектирования:

формирование требований;
изучение объекта автоматизации;
выбор и разработка варианта концепции системы.

Анализ материалов и разработка документации:

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

17.2. Эскизное, техническое – предварительное проектирование:

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

17.3. Рабочее - детальное проектирование:

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

17.4. Разработка информационной системы

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

17.5. Ввод информационной системы в эксплуатацию

ввод в опытную эксплуатацию технических средств;
ввод в опытную эксплуатацию программных средств;
обучение и сертифицирование персонала;
проведение опытной эксплуатации всех компонентов и системы в целом;
сдача в эксплуатацию и подписание актов приемки-сдачи работ.

17.6. Эксплуатация информационной системы

повседневная эксплуатация;
сопровождение программных, технических средств и всего проекта.


18. Состав и содержание работ на этапе разработки ИТ и ИС

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

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

18.1. Основные участники разработки

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

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

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

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

18.2. Документирование этапов разработки

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

Качество документации должно отвечать следующим критериям:

правильность:
соответствие (трассируемость) требований и спецификаций соответствующей системе, и наоборот;
последовательность в описании требований, спецификаций и функций;

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

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

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

Исходные коды

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

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

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

18.3. Ответственность заказчика

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

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

Оценка эффективности разработки

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

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

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

Стадии разработки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документ о завершении внедрения системы подписывают заказчик и разработчик.

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

19. СОСТАВ И СОДЕРЖАНИЕ РАБОТ НА ЭТАПЕ ВНЕДРЕНИЯ ИТ И ИС

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

19.1. Особенности внедрения

Внедрение, пожалуй, - самый ответственный момент проекта замены информационной системы. Это связано с рядом причин.

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

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

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

Организационные действия

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

Можно ли избежать этого? Ответ практикующих менеджеров проектов в 99,9% случаев - "да". Набор инструментов для достижения такого результата достаточно уникален и индивидуален и является во многом профессиональным ноу-хау (Know-How) руководителя проекта. Мы же рассмотрим некоторые основные составляющие таких организационных действий, которые позволяют сделать даже проблемное внедрение успешным.

Снятие противоречий и конфликтов

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

Прояснение недопониманий и выработка согласованных подходов

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

Прояснение формальной (юридической) позиции

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

Онлайн-менеджмент и контроль

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

Оперативный анализ рисков

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

Мотивация персонала на достижение результата

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

Информирование заинтересованных сторон

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

Планирование и обеспечение ресурсами

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

19.2. Подготовка к внедрению

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

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

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

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

19.3. Рабочая (промышленная) эксплуатация

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

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

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

В случае, если внедряемая система решает большой спектр задач, количество пользователей более 100, необходим поэтапный переход. Он может осуществляться в следующей последовательности:

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

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

19.4. Сопровождение проекта

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

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

[1]
Источник: Костров А.В. Основы информационного менеджмента. Москва, Финансы и статистика, 2001 – 336 с.

[2]
Источник: Jan 22, 2007 Title: Илья Штефан /Каким софтом пользоваться ИТ-директору? NetworkDoc.Ru

http://coder-web.net/index.php?mact=News,cntnt01,print,0&cntnt01articleid=25&cntnt01showtemplate=false&cntnt01returnid=15

[3]
Источник: Учебник «Информатика» Н.В. Макарова, 1997 г. http://synopsis.kubsu.ru/informatic/

[4]
Источник: А. М. Мартынович, В. И. Бузмаков, Стратегия развития информационной системы управления, журнал "Корпоративные системы" (№1, 2004)

http://www.intalev.ru/?id=5524

[5]
Источник :
Московский юридический институт МВД РФ, Кафедра управления и Информатики, А.А.Плинатус , С Б О Р Н И К Л Е К Ц И Й по курсу

"Информатика", Москва - 1996 http://referat.niv.ru/referat/014/01400178.htm

[6]
Источник: А. М. Мартынович, В. И. Бузмаков, Стратегия развития информационной системы управления, журнал "Корпоративные системы" (№1, 2004)

http://www.intalev.ru/?id=5524

[7]
Источник информации: http://it.taom.ru/book_units.php?id_book=1272

[8]
Источник: Шлаин Б.М Современные программные средства управления производством.
http://www.rinet.ru/~boris/Business/a5.htm

[9]
Источник: И. Карпачев - к
онсультант компании «Делойт и Туш СНГ»

[10]
Источник: С. В. Корнеев «Системы поддержки принятия решений в бизнесе», журнал "Сети & Бизнес"
(№6, 2005)

http://www.management.com.ua/ims/ims096.html

[11]

[12]
Источник: Дэниель Пауэр (Daniel Power)

[13]
Источник: Bonczek, Holsapple & Whinston, 1981

[14]

[15]
Источник: Дэниель Пауэр (Daniel Power)

[16]
Источник информации http://www.abc.org.ru/smd.html

[17]
Источник: http://www.abc.org.ru/smd.html

[18]
Источник ; Береза А.С, Прохоров В.П Концепция развития функций SCADA-системы TRACE MODE на основе технологии экспертных систем принятия и исполнения решений. Статья опубликована в журнале «ИСУП», № 1(5)_2005

http://isup.ru/index.php?option=com_content&task=view&id=308&Itemid=49

[19]