Обследование деятельности предприятия
При создании информационных систем часто предприятия используют консалтинговые услуги. Консалтинг является компонентом информационного менеджмента как составляющая процесса создания автоматизированных информационных систем.
Консалтинг — это деятельность специалиста или целой фирмы (КД), занимающихся стратегическим планированием проекта, анализом и формализацией требований к информационной системе, созданием системного проекта, иногда — проектированием приложений.
Но все это осуществляется до этапа собственно программирования или настройки каких-то уже имеющихся комплексных систем управления предприятием, выбор которых и осуществляется на основе системного проекта. Сюда не входит системная интеграция. Консалтинг предваряет и регламентирует названные этапы.
Основные цели разработки консалтинговых проектов:
1) представление деятельности предприятия (ДП) и принятых в нем технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения;
2) формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;
3) упорядочение информационных потоков (в том числе документооборота) внутри предприятия;
4) выработка рекомендаций по построению рациональных технологий работы подразделений предприятия и его взаимодействию с внешним миром;
5) анализ требований и проектирование спецификаций корпоративных информационных систем;
|
|
|
6) рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями, прежде всего классов MRP-II (manufacturing resource planning) и ERP (enterprise resource planning).
Структурный подход к разработке консалтинговых проектов приведен на рис. 4.1.
Этап 1 (анализ первичных требований и планирование работ) предваряет инициацию работ над проектом. Его основные задачи:
1) предварительное изучение задачи;
2) анализ первичных бизнес-требований;
3) предварительная экономическая оценка проекта;
4) построение плана-графика выполнения работ;
5) создание и обучение совместной рабочей группы.
Важнейшими на данном этапе являются и организационные мероприятия: должны быть изданы соответствующие приказы по проведению работ, назначены ответственные по направлениям - без подобной поддержки со стороны руководства предприятия бессмысленно вообще затевать консалтинговый проект.
Первый шаг собственно разработки — предварительное изучение задачи, которое должно ответить на ряд вопросов:
1. В чем заключаются недостатки существующей ситуаций?
2. Какие улучшения возможны?
3. На кого окажет влияние новая система?
|
|
|
Рис 4.1 Структура подхода
На данном этапе целесообразно построить обзорную диаграмму потоков данных для оценки существующей ситуации с целью ее использования для подгонки всех фрагментов друг к другу и выявления недостатков.
В результате предварительного изучения аналитик должен разумно оценить преимущества внедрений новой системы, а также обосновать временные затраты и стоимость следующего шага разработки — детального изучения. Результаты предварительного изучения рассматриваются руководством соответствующего уровня, на их основе может быть санкционирована возможность детального изучения.
Детальное изучение, включающее этапы 2—4, строится на фактах, выявленных во время предварительного изучения и проведения обследования деятельности предприятия, и предполагает более детальное и точное документирование ограничений существующей системы, а также уточнение функций этой системы до уровня, необходимого для написания спецификаций новой (модернизированной) системы.
В рамках этапа 2 (проведение обследования деятельности предприятия) осуществляется:
1) предварительное выявление требований, предъявляемых к будущей системе;
2) определение организационной и топологической структур предприятия;
|
|
|
3) определение перечня целевых задач (функций) предприятия;
4) анализ распределения функций по подразделениям и сотрудникам;
5) определение перечня применяемых на предприятии средств автоматизации.
При этом выявляются функциональная деятельность каждого из подразделений предприятия и функциональные взаимодействия между ними, информационные потоки внутри подразделений и между ними, внешние по отношению к предприятию объекты и внешние информационные взаимодействия.
По окончании обследования строится и согласуется с заказчиком предварительный вариант функциональной модели предприятия, включающей идентификацию внешних объектов и информационных взаимодействий с ними, а также детализацию до уровня основных видов деятельности предприятия и информационных связей между этими видами.
На этапе 3 (построение моделей деятельности предприятия) осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:
G модели «как есть», представляющей собой «снимок» положения дел на предприятии (организационная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнес-процессы и т.д.) на момент обследования и позволяющей понять, что делает и как функционирует данное предприятие с позиций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации;
|
|
|
G модели «как должно быть», интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия.
Главный результат детального изучения — этап 4 — построение системного проекта (модели требований), являющеюся первой фазой разработки собственно информационной системы (именно фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Системный проект строится на основе модели «как должно быть» и результатов обследования предприятия в части выявления требований к будущей системе.
При презентации системного проекта аналитик должен быть готов услышать больше критических замечаний, чем при использовании традиционных подходов, так как диаграммы легче понять, и обнаружить какие-либо несоответствия и ошибки. В результат презентации принимается решение о продолжении разработки или ее прекращении, а также устанавливается сумма бюджета проекта, поэтому аналитику необходимо создать несколько альтернативных моделей систем, имеющих разный набор преимуществ и предполагающих различные капиталовложения.
По завершении данного этапа (после согласования системного проекта с заказчиком) изменяется роль консультанта. Отныне он становится на сторону заказчика, одной из его основных функций на всех последующих этапах работ будет контроль на соответствие требованиям, зафиксированным в системном проекте.
После выбора системного проекта на основе выявленных и согласованных требований осуществляется разработка предложений по автоматизации — этап 5, включающий:
1) составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;
2) анализ применимости существующих систем управления предприятиями (прежде всего классов MRP и ERP) для решения требуемых задач и формирование рекомендаций по выбору такой системы;
3) совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;
4) разработка требований к техническим средствам;
5) разработка требований к программным средствам;
6) разработка предложений по этапам и срокам автоматизации.
На этапе 6 на основании принятых решений по автоматизации осуществляется преобразование системного проекта в технический проект (модель реализации), включающее следующие действия:
1) уточнение логической модели (разработка подробной логики каждого процесса с использованием диаграмм потоков данных и спецификаций процессов);
2) проектирование физической базы данных;
3) построение иерархии функций модулей, подлежащих программированию;
4) оценка затрат на реализацию.
Перечисленные работы должны выполняться консультантами совместно с проектировщиками системы: именно здесь и находится граница, разделяющая консалтинг и разработку. Тем не менее желательно, чтобы на этапе реализации системы консультант также действовал в интересах заказчика, а именно: контролировал соответствие создаваемой программной системы системному и техническому проектам, а также участвовал в работах по ее расширению и модификации, так как планирование расширений должно осуществляться на основе модели требований.
Проведение обследования. Обследование — важнейший и определяющий этап выполнения консалтинговых проектов, на его основе осуществляется вся последующая деятельность. По окончании обследования строится и согласуется с заказчиком предварительный вариант функциональной модели предприятия, включающей идентификацию внешних объектов и информационных взаимодействий с ними, а также детализацию до уровня основных видов деятельности предприятия и информационных связей между этими видами, в дальнейшем на основании согласованных моделей верхнего уровня и осуществляется построение детальных моделей.
Необходимо отметить, что каждый из участвующих в проекте системных аналитиков должен обследовать не более 2—3 видов деятельности предприятия (таких, как, например, учет кадров, бухгалтерия, маркетинг, ремонт оборудования, перевозки и т.п.), для того чтобы тщательно в них разобраться. Современное предприятие является сложной системой, состоящей из крупных взаимоувязанных подсистем (видов деятельности), а возможности человека в одновременном охвате большого количества таких подсистем ограничены.
Исходной информацией при проведении обследования и выполнении дальнейших этапов служат:
1) данные по организационной структуре предприятия;
2) информация о принятых технологиях деятельности;
3) стратегические цели и перспективы развития;
4) результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);
5) предложения сотрудников по усовершенствованию бизнес процессов предприятия;
6) нормативно-справочная документация;
7) данные по имеющимся на предприятии средствам и системам автоматизации;
8) опыт системных аналитиков в части наличия типовых решений.
При проведении обследования целесообразно применять следующие методы:
1. анкетирование;
2. сбор документов;
3. интервьюирование.
Анкетирование — начальный этап обследования, он предваряет выезд группы системных аналитиков на предприятие. Анкеты позволяют составить первоначальное представление о сферах деятельности предприятия, что дает возможность спланировать дальнейшее распределение работ группы аналитиков. Анкеты рассылаются руководителям структурных подразделений и содержат графы для идентификации фамилии и должности анкетируемого, отдельно в анкетах излагается просьба приложить шаблоны документов, с которыми работают сотрудники соответствующего под разделения. Список вопросов ограничен 15—20 вопросами с тем, чтобы вся анкета не занимала более двух листов. Примерный вариант анкеты приведен ниже
4. ФИО руководителя подразделения, телефон.
5. Координаты контактного лица (к кому в отсутствие или при занятости руководителя можно обращаться).
6. Каковы (с позиций вашего подразделения) должны быть цели создания интегрированной системы управления предприятием?
7. Основные функции подразделения.
8. Какая информация поступает из других подразделений (заявки, запросы, отчеты и т.п.)?
9. Какая информация передается в другие подразделения?
10. Какая информация формируется (рождается) в подразделении?
11. С какими внешними предприятиями (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается?
12. Физическое представление информационных потоков и хранилищ (документ, дискета, сеть, журнал, картотека и т.п.).
13. Время хранения информации.
14. Документы от и для руководства.
15. Штатная структура и квалификация кадров.
16. Техническое оснащение подразделения (компьютеры, сеть, модем и т.п.).
17. Используемые программные продукты.
18. Подпись.
Просьба приложить:
1) положение о подразделении;
2) набор документальных форм без внутреннего наполнения, т.е. используемые формы, бланки и др. (например, карточку складкою учета, отчет по форме N, наряд-задание, товарно-транспортную накладную).
Сбор документов должен осуществляться на всех этапах проведения обследования; соответствующие формы, бланки и т.п. в дальнейшем окажут неоценимую услугу при разработке информационной модели предприятия (выявлении сущностей информационной модели и наполнении их атрибутикой). В дальнейшем целесообразно подготовить альбом форм с разбивкой их по сфере деятельности предприятия.
Интервьюирование — важнейший и необходимый метод обследования, только с его помощью возможно разобраться во всех тонкостях применяемых на предприятии технологий. Современное предприятие — сложнейшая система, как оно функционирует, не знает ни один человек. Конечно, руководство представляет ситуацию в целом, с другой стороны, клерк досконально знает свою деятельность, но полной картины не имеет никто. И только интервьюирование представителей всех звеньев организационной структуры позволит выявить и в дальнейшем формализовать эту картину.
С другой стороны, интервьюирование является и наиболее сложной задачей: необходимо найти контакт с сотрудником и направить беседу в необходимое для аналитика русло. Ниже предлагаются несколько общих рекомендаций, касающихся линии поведения аналитика при интервьюировании:
G тезис в начале беседы — я ничего (или почти ничего) не знаю о вашей работе, расскажите как можно подробнее, чем вы занимаетесь;
G правило 1 — если вам начали подробно рассказывать технологию работы, ни в коем случае не перебивайте, необходимые уточнения можно сделать и в конце беседы,
G правило 2 — если в беседе участвуют несколько аналитиков, вести беседу и задавать уточняющие вопросы должен один из них, неясные для других вопросы проясняются в конце беседы;
G правило 3 — даже если вы прекрасно знаете предметную область, не говорите много сами и не учите интервьюируемого: в любом случае выявляются тонкости и детали, специфичные для данного предприятия и, естественно, вам не известные.
В принципе этих и подобных им правил достаточно для выявления в ходе беседы необходимой аналитику информации приблизительно у 90% интервьюируемых, а этого более чем достаточно в соответствии с законом «20 на 80». Тем не менее постараемся составить основанную на опыте типизацию остальных 10% и предложить возможные действия по выходу из тупика:
1) «отказник» — как правило, квалифицированный специалист, осознающий свою незаменимость. Обычно руководству известен его характер, поэтому необходимы жесткие меры: либо данная деятельность не будет включена в модель, либо она будет промоделирована на основании опыта и соображений здравого смысла;
2) «говорун» — как правило, руководитель среднего звена, понимающий, что по-старому работать нельзя, и хватающийся за любую возможность улучшить ситуацию. Очень полезный для поддержки проекта человек, тем не менее в беседе готов бесконечно обсуждать свои трудности и проблемы, получить от него необходимую для построения модели информацию практически невозможно. Единственный способ работы с ним — обсуждение уже построенной (пусть примитивной и во многом ошибочной) модели с целью ее доводки;
3) «балласт» — человек, давно работающий на предприятии и непонятно чем занимающийся. На вопросы «Какие функции вы выполняете?», «С какими документами вы работаете?» агрессивно повторяет, как попугай: «Я делаю все», «Со всеми документами», «Все документы ко мне приходят и все уходят». Какой-либо информации получить не удается по причине ее отсутствия. Естественно, никакого отражения подобной «деятельности» в модели не производится;
4) человек, занимающий экзотическую и малопонятную должность. Представляет собой модификацию варианта 3) с той лишь разницей, что реально деятельность существует и, следовательно, должна быть отражена в модели;
5) «мелкая сошка» — человек, не привыкший к проявлению интереса к себе и своей работе и занимающий низшую должность. При должном терпении реально получение того небольшого куска информации, которым он владеет. При обследовании диспетчерской службы одного из северных предприятий на одной из удаленных точек аналитик имел неосторожность во время непродолжительной беседы включить диктофон. Беседа была тут же прервана, и аналитику пришлось ждать минут сорок, пока интервьюируемая приводила себя в порядок: накладывала косметику и делала прическу!
Какую же информацию нужно выявлять прежде всего во время интервьюирования?
1. Необходимо ограничить контекст системы; с этой целью должны быть определены все внешние объекты, с которыми моделируемое предприятие взаимодействует, технологии взаимодействия со стороны предприятия, а также информационные (и, возможно, материальные) потоки, обеспечивающие эти взаимодействия.
2. Следует установить и детально проанализировать реальные технологии работы предприятия: нормативно-справочная документация (если она имеется) описывает их неполно.
3. Должны быть определены реальные функции подразделений и их взаимосвязи и взаимозависимости, поскольку положения о подразделениях такую информацию не содержат.
4. Выявляются и специфицируются все информационные хранилища (в том числе и бумажные: картотеки, архивы и т.п.).
5. Оценивается аппаратно-техническая база предприятия, а также исследуется работающее на ней программное обеспечение.
6. Собираются статистические данные по бизнес-процессам предприятия.
Остановимся на последнем более подробно.
Статистические данные при проведении обследования надо собирать по каждому объекту будущей модели: потоку данных, элементу данных, процессу, хранилищу данных, внешней сущности и т.п. Так, на этане анализа моделей наличие подробной статистики обеспечит их адекватную верификацию на полноту и непротиворечивость и позволит на начальных этапах выявить ошибки и узкие места в построенных моделях. В следующих пунктах будет показано, как эти статистические данные работают на дальнейших этапах, начиная с этапа выработки предложений по автоматизации и заканчивая собственно разработкой или внедрением выбранной системы.
1) Составные данные. Для составных данных статистика co6ирается, как правило, лишь для итеративных (повторяющихся) компонентов: необходимо точно знать количество итераций для каждого из них (например, заказ на книги включает в себя перечень заказанных книг с их атрибутами), поэтому для формирован требований к функции распечатки соответствующего бланка необходимо знать: сколько книг обычно заказывается? как час производится нетипичный заказ и каковы его размеры? сколько авторов обычно бывает у книги?..
Статистика по итеративным компонентам внутри составных данных в дальнейшем будет использоваться для проектировании экранов, отчетов и, естественно, при проектировании базы данных.
2) Элементы данных. О каждом элементе данных необходимо знать формат данных и допустимые значения этого элемента. Формат (включая тип) и физическая длина очень полезны при проектировании экранных форм и определении размеров баз данных.
3) Потоки данных. Такие характеристики потока, как скорость и интенсивность, являются необходимыми при определении требований к аппаратным (техническим) средствам. Кроме того, для любого составного потока данных полезно знать распределение компонентов внутри этого потока данных. Например, если в фирме «Рога и Копыта» заказ определяется, как заказ = {заказ на рога / заказ на копыта}, и выясняется, что 12% всех заказов составляют заказы на рога, 84% — на копыта, а 4% заказов — на заполнение стержней для шариковых ручек, то данная статистика может использоваться для определения пиковых нагрузок на соответствующие обрабатывающие процессы (а также, возможно, для принятия решения об оказании дополнительного вида услуги — upgrade стержней).
4) Процессы. Важнейшие характеристики процессов — частота и время выполнения. Именно здесь и лежит ключ к улучшению их функционирования. Кроме того, такие сведения являются необходимыми при определении требований к аппаратным средствам.
5) Хранилища данных. По хранилищам данных обычно собирается следующая информация: среднее количество записей в каждом хранилище данных, количество чтений, добавлений, изменений и удалений записей по каждому из процессов, включающих перечисленные действия. Проектировщик баз данных может использовать эту статистику для нескольких целей: например, решить вопрос, какой ключ считать первичным, сортировать ли хранилище и по какому ключу, решить, нужно ли завести дополнительную таблицу с целью обеспечения скорости доступа и т.д. Более того, к этой информации потребуется обратиться и при выборе подходящей СУБД, которая сможет обеспечить необходимую частоту и (или) гибкость доступа к данным.
Хронология доступа — также ценная информация. Так, запись о конкретном заказе, как правило, однажды создается и однажды удаляется. Но обычно доступ к этой записи осуществляется очень часто в начале ее существования (запросы о покупателе, счета, платежи, накладные) и крайне редко в дальнейшем (месячные и квартальные отчеты), что позволяет своевременно осуществлять ее архивацию.
6) Внешние объекты. Наконец, необходимо собрать определенную статистику об окружении, в котором система должна работать («ограничения окружения»). Наиболее важным здесь является количество пользователей, их способы использования системы и географическое распределение. По этой статистике можно будет сделать заключения о стоимости периферии, о типе системы телекоммуникаций и даже о том, как данные должны быть физически распределены для обеспечения удаленного доступа. Другие данные об окружении могут включать температуру, уровень шума, существующую отделку помещения, уровень радиации и т.п. Следует отметить, что часто возникает необходимость в проведении дополнительного обследования: какие-то моменты были не до конца выяснены, где-то возникли нестыковки, что-то было просто упущено. Обычно дополнительное обследование занимает два-три дня, и при его проведении очень полезно обсудить с интервьюируемыми уже наработанные модели.
Построение моделей
Модели деятельности предприятия. Построение и анализ моделей деятельности предприятия относится к области бизнес-консалтинга, включающего в себя построение моделей текущего и целевого состояния предприятия, выработку предложений по совершенствованию его деятельности, формирование целевой программы развития предприятия и плана перехода из текущего стояния в целевое. На данном этапе осуществляется обработка результатов обследования и построение функциональных, информационных и, если необходимо, событийных моделей технологий работы предприятия следующих двух видов:
G модели «как есть»;
G модели «как должно быть».
При этом переход от модели «как есть» к модели «как должно быть» обычно осуществляется следующими двумя способами:
1) совершенствованием технологий на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников («легкий» реинжиниринг);
2) радикальным изменением технологий и переосмыслением; бизнес-процессов («жесткий» реинжиниринг). Например, вместо попыток улучшения бизнес-процесса проверки кредитоспособности клиента, может быть, следует задуматься, а нужна ли вообще такая проверка? Возможно, затраты на такие проверки каждого из клиентов во много раз превышают убытки, которые может понести банк в отдельных случаях недобросовестности (в случае, когда клиентов много, а суммы сделок незначительны).
Необходимость подобного перехода и повлекла за собой создание подходов к реорганизации деятельности предприятий (реинжинирингу бизнес-процессов). В данном разделе рассматривается, собственно говоря, методика построения моделей деятельности.
В рамках создания моделей деятельности должен быть осуществлен:
1) анализ функциональной деятельности структурных подразделений предприятия;
2) анализ функционального взаимодействия структурных подразделений;
3) анализ внутреннего документооборота структурных подразделений; анализ информационных потоков и информационного взаимодействия структурных подразделений;
4) анализ применяемых в настоящее время средств автоматизации как в структурных подразделениях, так и на предприятия в целом.
По результатам анализа и моделирования осуществляется оценка эффективности деятельности структурных подразделений предприятия, на основе которой формируются предложения по совершенствованию его структуры, технологий работы структурных подразделений и предприятия в целом. Критериями такой оценки должны являться:
1) количество потребителей продукции предприятия;
2) стоимость издержек производства продукции;
3) длительность типовых операций производства продукции;
4) дублирование и противоречивость функций, информационных потоков и документооборота;
5) стоимость и длительность выполнения отдельных шагов технологии или отдельных технологических цепочек шагов;
6) дублирование и противоречивость выполнения отдельных шагов технологии или отдельных технологических цепочек шагов;
7) степень загруженности структурных подразделений и должностных лиц;
8) степень загруженности оборудования, используемого при реализации отдельных шагов технологии или технологических участков;
9) степень применения средств автоматизации при поддержке выполнения отдельных шагов технологии или отдельных технологических цепочек шагов
Результат проведения анализа и оценки — предложения по совершенствованию деятельности предприятия, а именно:
1) по изменению технологий целевой и обеспечивающей деятельности предприятия, операций учета, планирования, управления и контроля;
2) по построению рациональных технологий работы структурных подразделений предприятия с учетом существующих автоматизированных систем;
3) по созданию перспективной организационной структуры предприятия, осуществляющей реализацию рациональных технологий работы;
4) по изменению информационных потоков и документооборота, обеспечивающих реализацию рациональных технологий работы;
5) по разработке проектов схем внутреннего и внешнего документооборота, проекта положения о документообороте, проекта альбома форм входных и выходных документов.
На основе разработанных и согласованных предложений формируется целевая программа развития предприятия и план мероприятии по переходу из текущего состояния в целевое. Целевая программа развития предприятия должна включать долгосрочные решения, цели, задачи и основные параметры развития. План мероприятий перехода из текущего состояния в целевое содержит:
1) последовательность, формы, способы и время выполнения задач, поставленных структурным подразделениям предприятия;
2) распределение сотрудников структурных подразделений и материальных средств по решаемым задачам;
3) порядок информационного и других видов взаимодействия структурных подразделений и органов управления.
В связи с вышесказанным каждая из моделей деятельности включает:
1) полную функциональную модель с глубиной проработки до уровня конкретного действия должностного лица структурного подразделения предприятия;
2) информационную модель, интегрированную с функциональной моделью;
3) динамические, стоимостные, событийные и т.п. модели для осуществления соответствующих оценок.
Ниже перечислены основные виды и последовательность работ, рекомендуемые при построении моделей деятельности.
1) Разработка структурной функциональной модели деятельности предприятия:
G определение информационных потоков между основными процессами деятельности, связей между процессами и внешними объектами; оценка объемов и интенсивности информационных потоков;
G разработка иерархии диаграмм, образующих структурную функциональную модель деятельности предприятия;
G анализ и оптимизация структурной функциональной модели
2) Разработка информационной модели предприятия:
G определение сущностей модели и их атрибутов;
G проведение атрибутного анализа и оптимизация сущностей, идентификация отношений между сущностями и определение типов отношений;
G разрешение неспецифических отношений;
G анализ и оптимизация информационной модели.
3) Разработка событийной модели предприятия:
G идентификация перечня состояний модели и определение возможностей переходов между состояниями;
G определение условий, активизирующих переходы, и действий, влияющих на дальнейшее поведение;
G анализ и оптимизация событийной модели.
Следует отметить, что построенные модели деятельности — не просто промежуточный результат, используемый консультантом для выработки каких-либо рекомендаций и заключений. Они представляют собой самостоятельный результат, имеющий большое практическое значение, в частности:
G модели позволяют осуществлять автоматизированное и быстрое обучение новых работников конкретному направлению деятельности предприятия (так как ее технология содержится в модели) с использованием диаграмм;
G с их помощью можно осуществлять предварительное моделирование нового направления деятельности с целью выявления новых потоков данных, взаимодействующих подсистем и бизнес-процессов.
Ниже приводятся некоторые основополагающие рекомендации по структурированию моделей деятельности.
1. Основной принцип заключается в том, что структурирование должно осуществляться в соответствии со сферами деятельности и бизнес-процессами предприятия, а не в соответствии с его организационной структурой. Именно бизнес-процессы представляют ценность для клиента, и именно их улучшением предстоит в дальнейшем заниматься консультанту. Модель, основанная на бизнес-процессах, содержит в себе (не всегда в явном виде) и организационную структуру предприятия.
2. Верхний уровень модели отражает только контекст системы — взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром и ничего более.
3. На втором уровне модели воспроизводятся основные этапы деятельности предприятия и их взаимосвязи. Например, для автотранспортного предприятия одним из решений может быть выделение следующих видов деятельности: Эксплуатация автотранспорта, Ремонт и техническое обслуживание, Контроль безопасности, Управление производством, Обеспечивающая деятельность. В случае большого количества сфер деятельности некоторые из них можно вынести на третий уровень модели. Так, Обеспечивающая деятельность может включать в себя Учет кадров, Бухгалтерский учет, Экономическое планирование, Материально-техническое снабжение, Складской учет и т.п. Но в любом случае под деятельность необходимо отводить не более двух уровней модели.
4. Каждая деятельность в свою очередь детализируется на бизнес-процессы (желательно, единственного уровня). Например, деятельность по Учету кадров включает в себя такие бизнес-процессы: Прием на работу, Увольнение и т.п.
5. Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций. Так, процесс Прием на работу содержит в себе функции: Прием заявления, Оформление приказа, Регистрацию и др. Обычно для моделирования бизнес-функции до статочно 2—3 уровней детализации, завершающейся описанием элементарного алгоритма с помощью миниспецификации.
6. Таким образом, общее число уровней в модели не должно превышать 6—7. Практика показывает, что этого вполне достаточно для построения полной модели деятельности современного предприятия любой отрасли.
Разработка системного проекта. Создание системного проекта (т.е. модели требований к будущей системе) — первая фаза разработки собственно информационной системы (фаза анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Системный проект строится на основе модели «как должно быть» и результатов обследования предприятия в части выявления требований к будущей системе.
Фактически на данном этапе дается ответ на вопрос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.
На этом этапе определяются:
1) архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;
2) интерфейсы и распределение функций между человеком и системой;
3) требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;
4) состав людей и работ, имеющих отношение к системе;
5) ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
В рамках системного проектирования должно быть осуществлено:
1) определение состава, структуры и характеристик функциональных задач в пределах деятельности структурных подразделений;
2) определение состава и структуры программных средств автоматизации технологии решения задач с учетом существующих средств в структурных подразделениях;
3) определение структуры и характеристик информационного обеспечения технологии решения задач;
4) разработка технических решений по построению информационного обеспечения (логических структур баз данных, структур классификаторов);
5) разработка состава автоматизируемых процедур документооборота.
Системный проект должен включать:
1) полную функциональную модель требований к будущей системе;
2) комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);
3) пакет отчетов и документов по функциональной модели, включающий характеристику объекта моделирования, перечень подсистем, требования к способам и средствам связи для информационного обмена между компонентами, требования к характеристикам взаимосвязей системы со смежными системами, требования к функциям системы;
4) концептуальную модель интегрированной базы данных (пакет диаграмм);
5) архитектуру системы с привязкой к концептуальной модели;
6) предложения по организационной структуре для поддержки системы.
Таким образом, системный проект содержит функциональную, информационную и, возможно, событийную модели требований к будущей системе. Виды и последовательность работ при построении этих моделей требований аналогичны соответствующим работам по построению моделей деятельности. Дополнительно системный проект включает в себя техническое задание на создание информационной системы.
Системный проект, позволяет:
1) описать, увидеть и скорректировать будущую систему до того, как она будет реализована физически;
2) уменьшить затраты на разработку и внедрение системы;
3) оценить разработку по времени и результатам;
4) достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.);
5) улучшить качество разрабатываемой системы, а именно: создать оптимальную структуру интегрированной базы данных, выполнить функциональную декомпозицию типовых модулей.
Техническое проектирование
Предложения по информатизации. После построения системного проекта, содержащего требования к будущей системе, на его основе осуществляется разработка предложений по информатизации предприятия, включающая:
1) составление перечня автоматизированных рабочих мест предприятия, их состава и структуры, а также способов и схем информационного взаимодействия между ними;
2) разработку требований к техническим средствам;
3) разработку требований к программным средствам;
4) разработку топологии, состава и структуры локальной вычислительной сети;
5) анализ имеющихся на рынке систем управления предприятием с учетом их соответствия системному проекту и формирование рекомендаций по выбору такой системы;
6) совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием (или отдельных ее элементов) или о разработке собственной системы;
7) разработку предложений по этапам и срокам внедрения информационной системы.
Далее рассматриваются общие соображения по выбору программного и технического (аппаратного) обеспечения, который необходимо сделать прежде, чем приступить к детальному проектированию.
1) Обозначение границ реализации. Практически любая система может быть разбита на части, отражающие четыре основных типа реализации систем: ручную, пакетную, диалоговую, реального времени. Из этих четырех типов первый реализуется людьми, остальные три являются автоматическими реализациями системы. Рассмотрим критерии назначения частям системного проекта наиболее приемлемых для них типов реализации.
Ручная реализация имеет три основных преимущества перед автоматической:
G процессы не требуется заранее точно определять. По крайней мере они могут определяться не так тщательно, как при автоматической реализации: люди хорошо знают, как заполнить пробелы в спецификации;
G ручная система может откликаться на неожидаемые запросы, а не только на заранее планируемые. Например, ручная система бронирования авиабилетов может ответить на запрос о возможности парковки автомобиля около аэропорта
G система может быть реализована в окружении, где автоматизация невозможна по целому ряду причин, например, психологических: хотя и возможно полностью автоматизировать процесс предоставления ссуды, люди не могут примириться с тем, что их прошения беспристрастно отклонены машиной.
После определения границ ручной реализации необходимо решить, какая часть системы будет пакетной, а какая диалоговой. Для большинства современных приложений вся информационная система должна быть диалоговой, если только не доказано противное. Соответствующее заключение может быть сделано на основе собранных статистических данных, например скорости поступления запросов и частоты изменения данных. В качестве примеров причин для пакетной реализации можно привести следующие:
G некоторые запросы требуют длительной работы со срезом базы данных за определенный период (годовой отчет, пересылка накопленной информации и т.п.);
G некоторые отклики (например, отчеты о продажах) содержат большое количество статичных данных, актуальность которых не изменяется в течение дней или даже недель.
Следующий шаг — выделение частей, реализуемых как подсистемы реального времени. Существует два принципиальных отличия системы реального времени от просто диалоговой системы. Первое из них связано с концептуальным уровнем: в системе реального времени время поступления события в систему само по себе несет определенную информацию, которая не может быть закодирована. Второе связано с уровнем реализации: время отклика системы реального времени является критичным и сопоставимым со скоростью выполнения технологических операций. В целом рекомендуется реализовать как подсистемы реального времени те части системы, из которых должен быть исключен человек, т.е. те части, где приоритетны следующие факторы: скорость (например, противоракетная оборона), опасность (например, контроль радиоактивности), утомляемость (работа авиадиспетчера).
2)Выбор подходящих технических средств. Разработав системный проект и определив границы реализации, можно начинать выбор аппаратной платформы, на которой будет функционировать система (или по крайней мере сужать область для такого выбора).
3) Анализ и выбор существующей системы. Зная типы подсистем и потенциальную аппаратную платформу, можно приступать к поиску коммерческих пакетов, удовлетворяющих требованиям, выявленным и зафиксированным на этапе системного проектирования, и которые могут справиться с размерами и мощностью, определяемыми собранной статистикой. Следует отметить, что к такому выбору необходимо подходить обосновано, т.к. стоимость интегрированной системы (включая ее внедрение на предприятии), в комплексе решающей стоящие перед предприятием задачи, может составлять сотни тысяч и миллионы долларов
Ниже перечислены некоторые из критериев выбора готовой системы:
1) поддержка большинства функций, выявленных при анализе требований;
2) поддержка концептуальной модели данных;
3) наличие высокоуровневых механизмов разработки для компенсации отсутствующих данных и функций;
4) функционирование на различных аппаратных платформах,
5) достаточные размеры внутренних таблиц;
6) локализация.
Помимо чисто технических критериев выбора, важную роль играют также деловые критерии, например опыт внедрения и надежность продавца.
4) Разработка собственной системы. Отметим недостатки такого подхода по сравнению с покупкой готовой системы:
G трудозатраты на создание собственной интегрированной системы огромны и составляют сотни и тысячи человеко-лет, стоимость разработки соизмерима со стоимостью готовой системы (а часто значительно превышает ее): такие продукты должны реализовываться большими коллективами программистов;
G использование готовой системы менее рискованно, чем разработка собственной;
G готовая система внедряется поэтапно и поэтому частично может быть доступна в рабочем режиме гораздо быстрее, чем собственная.
Техническое проектирование. На данном этапе на основе системного проекта и принятых решений по информатизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос «Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?». Этот этап разделяется на два подэтапа:
1) проектирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;
2) детальное проектирование, включающее разработку спецификаций каждой компоненты, разработку требований к тестам и плана интеграции компонент, а также построение моделей иерархии программных модулей и межмодульных взаимодействий и проектирование внутренней структуры модулей.
При этом происходит расширение системного проекта:
G за счет его уточнения;
G за счет построения моделей автоматизированных рабочих мест, включающих подсхемы информационной модели и функциональные модели, ориентированные на эти подсхемы вплоть до идентификации конкретных сущностей информационной модели;
G за счет построения моделей межмодульных и внутримодульных взаимодействий.
Тема 5.
Проектирование корпоративных информационных систем
Современные корпоративные автоматизированные информационные системы (КАИС или АИС) относятся к числу наиболее сложных систем, создаваемых человеком. Методы и средства их создания развиваются быстрыми темпами в качественном и количественном отношениях, вовлекая в русло системной интеграции все большее число специалистов.
Переход к информационной экономике и формирование рынка информационных ресурсов, широкое использование современных информационных технологий предполагают наличие серьезной нормативно-правовой и методической поддержки экономических информационных систем, учитывающей интеграцию и совместимость информационных процессов, персональную ориентацию проектных решений, автоматизацию проектирования, гарантии качества проектных и информационных технологий и услуг. При проектировании АИС должны быть обеспечены:
• эффективная поддержка принятия проектных решений на основе действующих нормативно-правовых документов, стандартов, методик и технологий проектирования;
• высокий уровень проектных решений, реализующий необходимый срок эксплуатации до модернизации и реконструкции системы;
• дружественные и технологичные проектные интерфейсы с разработчиками, учитывающие возможности обучения и повышения квалификации;
• эффективные средства управления проектированием и обеспечения информационной безопасности проектных работ.
Системный подход к разработке АИС, учитывающий требования внутренней и внешней совместимости, наличия возможностей их интеграции, модернизации, реконструкции и развития, предполагает обязательную проработку и единообразие методического обеспечения АИС и их компонентов на различных стадиях проектирования. Регламентация вопросов методического обеспечения АИС на различных стадиях проектного цикла позволяет скоординировать и гармонизировать требования к АИС по их нормативно-правовому и информационному взаимодействию, что позволит создать предпосылки к организации единого информационного пространства государства, формированию цивилизованного рынка информационных ресурсов, перехода к информационной экономике.
В узкоспециальном плане системное проектирование рассматривается как набор методов и организационная дисциплина, предназначенные для проектирования информационных систем определенных видов. Пояснение предмета представлено перечислением основных классов тех ИС, к проектированию которых относятся рассматриваемые методы:
• общеуправленческие ИС (MIS — management information system и EIS — executive information system);
• специализированные ИС по отраслям производства, например банковские учетные и управленческие системы, управление дискретным промышленным производством, системы профилактической и режимной деятельности органов МВД и др.;
• специализированные ИС по видам деятельности, например управление работой склада, система маркетинговых исследований, аналитическая система для работы на фондовом рынке и др.;
• адаптивные универсальные ИС по применяемым методам обработки информации, например электронный архив, корпоративная система управления процессом выполнения офисных работ, система статистических расчетов и др.
Таким образом, в ИС включаются и те типы систем, которые еще десять — пятнадцать лет назад рассматривались как отдельные от ИС: диалоговые системы решения задач и системы управления различными технологическими процессами (как ИС не рассматриваются системы прямого управления механизмами и агрегатами, но возможно их использование как компонентов ИС).
Для проектирования специализированной ИС или адаптации универсальной ИС к требованиям и нуждам конкретного заказчика применяется во многом общий набор методов и технологий. Этот набор составляет основу дисциплины «системного проектирования» — того специфического знания, которое вместе со знаниями о конкретном предприятии и его технологиях используется при построении любой автоматизированной информационной системы.
Этапы проектирования информационных систем. К проектированию АИС непосредственное отношение имеют два направления деятельности:
1) собственно проектирование АИС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки;
2) проектирование упомянутых компонентов АИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных информационных систем.
Сущность первого направления может быть выражена словами системная интеграция. Разработчик АИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов АИС (например, Price Waterhouse, Jet Info, Consistent Software и др.).
Второе направление в большей мере относится к области разработки математического и программного обеспечения для реализации функций АИС — моделей, методов, алгоритмов, программ на базе знания системотехники, методов анализа и синтеза проектных решений, технологий программирования, операционных систем и т.п. В каждом классе АИС (АСУ, САПР, ГИС и т.д.) имеются фирмы, специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Каждая из них рекламирует свою технологию создания АИС и придерживается стратегии либо тотального поставщика, либо открытости и расширения системы приложениями и дополнениями третьих фирм.
Как собственно АИС, так и компоненты АИС являются сложными системами, и при их проектировании целесообразно использовать нисходящий стиль блочно-иерархического проектирования, включающего ряд уровней и этапов.
Верхний уровень проектирования АИС часто называют концептуальным проектированием. Концептуальное проектирование выполняется в процессе предпроектных исследований, формулировки технического предложения, разработки эскизного проекта.
Предпроектные исследования проводятся путем анализа (обследования) деятельности предприятии (компании, учреждения, офиса), на котором создается или модернизируется АИС. Перед обследованием формируются и в процессе его проведения уточняются цели обследования — определение возможностей и ресурсов для повышения эффективности функционирования предприятия на основе автоматизации процессов управления, проектирования, документооборота. Содержание обследования — выявление структуры предприятия, выполняемых функций, информационных потоков, имеющихся опыта и средств автоматизации. Обследование проводится системными аналитиками (системными интеграторами) совместно с представителями организации-заказчика.
На основе анализа результатов обследования разрабатывается исходная концепция АИС, включающая предложения по изменению структуры предприятия, взаимодействия подразделений, по выбору базовых программно-аппаратных средств, предложения должны учитывать прогноз развития предприятия. В отношении аппаратных средств, и особенно программного обеспечения, такой выбор чаще всего есть выбор фирмы — поставщика необходимых средств (или по крайней мере базового ПО), так как правильная совместная работа программ разных фирм достигается с большим трудом.
В концепции может быть предложено несколько вариантов выбора. При анализе выясняются возможности покрытия автоматизируемых функций имеющимися программными продуктами и, следовательно, объемы работ по разработке прикладного ПО. Подобный анализ необходим для предварительной оценки временных и материальных затрат на автоматизацию. Учет ресурсных ограничений позволяет уточнить достижимые масштабы автоматизации, выполнить разделение создания АИС на работы первой, второй и т.д. очереди.
Результаты анализа — техническое предложение и бизнес-план создания АИС — представляются заказчику для окончательного согласования.
Как на этапе обследования, так и на последующих этапах целесообразно придерживаться определенной дисциплины фиксации и представления получаемых результатов, основанной на той или иной методике формализации спецификаций Формализация нужна для однозначного понимания исполнителями и заказчиком требований, ограничений и принимаемых решений.
При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают модели преобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, — модели его функционирования. В процессе разработки АИС модели, как правило, претерпевают существенные изменения, и в окончательном виде они рассматриваются уже как модели проектируемой АИС.
Различают функциональные, информационные, поведенческие и структурные модели. Функциональная модель системы описывает совокупность выполняемых системой функций. Информационные модели отражают структуры данных — их состав и взаимосвязи. Поведенческие модели описывают информационные процессы (динамику функционирования), в них фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий. Структурные модели характеризуют морфологию системы (ее построение) — состав подсистем, их взаимосвязи.
Содержание последующих этапов нисходящего проектирования — определение перечней приобретаемого оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое проектирование баз данных и их первоначального наполнения, разработка собственного прикладного ПО, которая в свою очередь делится на ряд этапов нисходящего проектирования.
Особое место в ряду проектных задач занимает разработка проекта корпоративной телекоммуникационной сети, поскольку техническое обеспечение АИС имеет сетевую структуру.
Если территориально АИС располагается в одном здании или в нескольких близкорасположенных зданиях, то корпоративная сеть может быть выполнена в виде совокупности нескольких локальных подсетей типа Ethernet или Token Ring, связанных опорной сетью типа FDDI, ATM или высокоскоростными вариантами Ethernet. Кроме выбора типов подсетей, связных протоколов и коммутационного оборудования приходится решать задачи распределения узлов по подсетям, выделения серверов, выбора сетевого ПО, определения способа управления данными в выбранной схеме распределенных вычислений и т.п.
Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом прежде всего рассматривается возможность использования услуг Internet. Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.
Ход развития информационных технологий позволяет сделать вывод, что мировое сообщество переходит на технологии создания открытых информационных систем.
Дата добавления: 2018-11-24; просмотров: 2024; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!