Реализация этапа на основе методологий пакета
Oracle Designer /2000
Более мощный инструмент подобного типа имеется в Oracle Designer/2000 – это Process Modeler. Его уникальным свойством является возможность создания моделей процессов, представляющих отделы, подразделения или отдельных работников компании со свойственными им бизнес-процессами, потоками данных и операциями по сохранению данных [12].
Кроме этого можно перейти от процессов верхнего уровня к процессам нижнего уровня и отражающим их моделям подпроцессов, то есть можно декомпозировать шаги процессов по аналогии с декомпозицией функциональных блоков в методологии IDEF0. Количество уровней декомпозиции не ограничивается.
Эта модель представляет последовательность шагов процессов, создающих услугу или изделие в рамках предприятия, а также информационный поток между ними. Данные, полученные из диаграммы процессов, хранятся в репозитарии (Repository) и доступны для использования другими инструментальными средствами Designer/2000. В частности, шаги процессов хранятся в репозитарии как функции, к которым можно получить доступ при использовании Function Hierarchy Diagrammer в целях построения функциональной диаграммы в автоматическом режиме.
Запуск утилиты Process Modeler производится из окна Designer/2000 щелчком по соответствующему ярлыку.
Для включения режима создания новой диаграммы необходимо выполнить команду File / New Diagram. В появившемся диалоговом окне необходимо ввести имя модели процессов и щелкнув по клавише <Enter>, получают режим построения новой диаграммы (модели) процессов.
|
|
|
Вначале необходимо построить организационные единицы ( Organization Unit ), которые аналогичны «плавательным дорожкам» диаграммы Swim Lane: имя организационной единицы размещается в левой части полосы, а справа от имени размещается трасса потока: шаги процесса (аналог работ IDEF3), хранилища и пункты принятия решений (логический элемент да/нет) (рис. 7.9).
Для построения организационной единицы необходимо щелкнуть по кнопке Organization Unit на панели инструментов и в появившемся окне ввести параметры новой организационной единицы: название (полное и краткое), текстовое описание и щелкнуть на клавише ОК. На экране появляется новая организационная единица. В качестве названия организационных единиц используют название отделов, подразделений, должностей и т.п., которые участвуют в выполнении моделируемого бизнес-процесса.
Для организационных единиц можно указать отношение родитель-сын (например, в подчинении у зам. директора по кадрам находятся отдел кадров, отдел охраны, канцелярия и т.п.). Это отношение будет графически отображено на диаграмме.
Для построения шага процесса, хранилища или пункта принятия решения необходимо установить курсор на соответствующую полосу (организационную единицу) и щелкнуть клавишей мыши, что приведет к появлению окна Create Process Step. В это окно вводится имя процесса и выбирается из списка тип процесса (шаг процесса, хранилище или пункт принятия решения). Можно ввести также время и стоимость для шага процесса, текстовое описание, средства мультимедиа для отображения его в пиктографическом режиме. Щелкнув по кнопке ОК, получают отображение объекта на соответствующей полосе.
|
|
|
Для редактирования этих объектов используется редактор Edit Process Step , который вызывается двойным щелчком мыши по соответствующему шагу процесса.
Рис. 7.9. Диаграмма из модели процессов «Выдача разрешения на торговлю»
Все объекты на модели процессов соединяются потоками (дугами), которые отображают движения информации или материалов. Они создаются с помощью кнопки Create Flow на панели инструментов.
После активизации этой кнопки следует щелкнуть поочередно на предыдущем и последующем шагах процесса для получения диалогового окна построения потока между этими объектами. В окне выбирают тип потока (данные, материалы, временной или просто поток), вводят имя потока, продолжительность и стоимость передачи. Для добавления потока в диаграмму следует щелкнуть по клавише ОК.
|
|
|
В модели процессов используется еще входной триггер и выходной триггеры. Входной триггер представляет собой событие, с которого начинается бизнес-процесс, например поступление товара на склад. Выходной триггер выражает результат выполнения бизнес-процесса, например сформированная накладная на выдачу товара.
Для создания входного триггера необходимо щелкнуть по кнопке Create Trigger на инструментальной панели, щелкнуть затем по соответствующему шагу процесса и в появившемся диалоговом окне ввести имя триггера («Поступление товара на склад»). Затем щелкнуть по кнопке ОК.
Для создания выходного триггера следует щелкнуть по кнопке Create Outcome и выполнить те же действия.
Для декомпозиции шагов процессов модели следует выделить родительский шаг процесса и выполнить команду File / Open Down. Эта процедура открывает новую дочернюю диаграмму, на которую автоматически передаются организационные единицы родительской диаграммы.
Из них оставляют только те, которые необходимы для нового уровня декомпозиции, и при необходимости добавляют новые. Процесс построения дочерней модели аналогичен: на диаграмму помещаются функции (шаги процесса), потоки, места хранения и пункты принятия решений. На рис. 7.10 представлена дочерняя диаграмма для блока А5 (рис. 7.9).
|
|
|
Количество уровней иерархий в модели не ограничивается – декомпозиция шагов процесса осуществляется до тех пор, пока каждый шаг процесса можно будет реализовать одним программным модулем. Переход из диаграммы нижнего уровня на более верхний обеспечивается командой File / Open Up.
Для отображения на мониторе полученной модели процессов Process Modeler имеет 3 режима:
- Symbol (по умолчанию) – используется два вида графических объектов;
- Enhanced Symbol – расширенная версия, для каждого вида объектов используется свое графическое изображение;
- Iconic – все объекты отображаются пиктограммами, которые в этом режиме оживляются, обеспечивая режим анимации.
Диаграммы в Process Modeler могут иметь мультимедийное расширение, поэтому можно показать, например движущееся представление потоков от одного шага процесса к другому. Можно встроить видео- и аудиоклипы для подчеркивания или пояснения шагов процессов.
Допустимо создать ссылку на внешнюю программу, например для запуска презентационных слайдов, либо вывести электронную таблицу или график, отображающие операции процесса. Можно промоделировать временную последовательность после присваивания шагам процессов характеристик времени. Затем можно запустить диаграмму на выполнение, наблюдая последовательное выполнение шагов процессов, отображенных в виде пиктограмм, за установленное время.
При этом можно убедиться в одновременности наступления событий или выяснить узкие места в работе системы. Все отмеченные возможности позволяют в наглядной форме донести до заказчика и будущих пользователей цели и намерения разработчиков.
Для сохранения модели процессов следует выполнить команду File / Save Diagram, для закрытия Process Modeler – команду File / Exit.
На основе этой модели процесса можно в автоматическом режиме построить функциональную иерархическую модель системы «AS IS», в которой каждому шагу процесса будет соответствовать функциональный блок.
Утилита Function Hierarchy Diagrammer позволяет отображать функции системы в иерархическом или многоуровневом представлении. В отличие от IDEF0-модели эта диаграмма размещается на одном листе и более похожа на типичную организационную диаграмму.
На этой функциональной диаграмме представляется деятельность организации с точки зрения задач, но при этом не выделяются группы пользователей, отделов, потоков данных или мест хранения данных. Линии между функциями означают не потоки информации, а представляют взаимосвязи «родитель-потомок» (рис 7.11).
Фактически эта диаграмма аналогична дереву узлов для IDEF0-модели, но с тем отличием, что можно закрыть дочерние уровни, щелкнув дважды по красному кружку со знаком минус у родительской функции, либо показать дочерние уровни, щелкнув по красному кружку со знаком плюс. Для отображения всех дочерних и всех родительских функций необходимо выполнить команду Layout / Expand Tree.
Рис. 7.10. Диаграмма декомпозиции блока А5
На диаграмме можно вводить новые функции, перетаскивать дочерние функции к другим родителям, изменять функции родителей и т.д. Однако лучше делать эти изменения на модели процессов, которая является основным источником информации для проектировщиков, а функциональная диаграмма более полезна в качестве единого представления всех функций системы в их иерархической упорядоченности.
Для запуска режима построения функциональной диаграммы необходимо в диалоговом окне Designer/2000 щелкнуть по ярлыку Function Hierarchy. На экран будет выдано диалоговое окно Function Hierarchy Diagrammer, в котором надо выполнить команду File / New , и в открывшемся диалоговом окне ввести имя функциональной диаграммы и имя модели процессов, на основе которой эта диаграмма будет строиться.
Щелкнув по кнопке ОК, получают функциональную иерархическую диаграмму системы, которую можно легко редактировать: обеспечивать вертикальную, горизонтальную или гибридную компоновку; перемещать функции по диаграмме, изменять родительские (корневые) функции и т.п.
Для сохранения диаграммы выполняется команда File / Save . Результатом выполнения этапа является оформление отчета, который должен включать разделы, определяющие цели и ограничения при создании ИС, ее функции и задачи, входная и выходная информация и т.д.
Этап разработки концепции ИС
7.2.1. Построение модели “ AS IS ”
Целью этапа является более детальное изучение объекта информатизации с помощью функциональных иерархических моделей «AS IS» («как есть») и разработка альтернативных вариантов создаваемой системы в виде функциональных моделей «TO BE» («как должно быть») или моделей процессов с помощью Process Modeler.
Результатом этапа является выбор оптимальной концепции построения ИС в виде функциональной модели «TO BE», логической модели базы данных и предложений по составу пользовательского интерфейса. Для модели процессов можно также построить функциональную модель «TO BE», но она будет выполнять вспомогательную роль. Методологические основы построения модели «TO BE» одинаковы для функциональных моделей (на базе IDEF-методологий) и для моделей процессов (на базе Process Modeler), поэтому в дальнейшем работать будем только с IDEF-моделями.
Рис. 7.11. Функциональная иерархическая диаграмма
Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятельности организации, анализ преимуществ новых бизнес-процессов и степени изменения существующей структуры организации бизнеса [20].
Анализ недостатков и «узких мест» начинается с построения модели «AS IS», то есть модели существующей организации работы. Модель «AS IS» строится на основании организационной диаграммы, диаграмм Swim Lane, модели процессов, которые были построены на предыдущем этапе. При этом продолжается дополнительное изучение документации (должностных инструкций, положений о предприятии, приказов, отчетов внутренних и для вышестоящих органов и т.п.), анкетирование и опрос служащих предприятия, создания фотографий рабочего дня будущих пользователей системы и других источников.
При разработке модели необходимо исходить из тех позиций, что каждый бизнес-процесс является объектом управления, выход которого представляет собой определенную ценность как для внутреннего клиента, так и для внешнего (потребители продукции или услуг, акционеры, банки, налоговые органы и т.п.). Обычно процессы подразделяют на основные и вспомогательные [27].
К основным процессам организации обычно относят процессы производства, сбыта и снабжения (процессы маркетинга, закупок, производства, хранения, поставки и сервисного обслуживания), то есть процессы, добавляющие ценность.
Вспомогательные процессы не добавляют ценности, но увеличивают стоимость изделия или услуги. К таким процессам относят управление персоналом, управление документацией, техническое обслуживание оборудования, бюджетное управление и т.п.
При построении иерархической модели принципиально важно правильно определить состав функций на различных уровнях декомпозиции и сформировать содержание бизнес-процессов.
В качестве примера можно привести структуру несложных процессов [27], которые могут оказать помощь начинающему системному аналитику при выделении основных процессов организации и построения функциональной модели проектируемой системы.
1. Анализировать рынок и потребности клиентов.
1.1. Определять потребности и пожелания клиентов.
1.1.1. Выполнять качественные оценки.
1.1.1.1. Проводить интервьюирование клиентов.
1.1.1.2. Проводить анализ с помощью фокус-групп.
1.1.2. Выполнять количественные оценки.
1.1.2.1. Подготавливать и проводить инспекции.
1.1.3. Прогнозировать покупательский спрос.
1.2. Измерять степень удовлетворенности потребителей.
1.2.1. Осуществлять мониторинг удовлетворенности продуктами и услугами.
1.2.2. Осуществлять мониторинг удовлетворенности потребителей при разрешении споров.
1.2.3. Осуществлять мониторинг удовлетворенности потребителей от взаимодействия с представителями компании.
1.3. Осуществлять мониторинг изменений на рынке или в ожиданиях потребителей.
1.3.1. Определять недостатки в предложении продуктов/услуг.
1.3.2. Идентифицировать инновации, направленные на обеспечение потребностей потребителей.
1.3.3. Определять реакцию потребителей на конкурирующие предложения.
2. Разрабатывать продукты или услуги.
2.1. Создавать концепцию и план разработки продукта/услуги.
2.1.1. Переводить потребности и желания потребителей в требования к продукту/услуге.
2.1.2. Планировать и детализировать цели по качеству продукта/услуги.
2.1.3. Планировать и детализировать цели по стоимости продукта/услуги.
2.1.4. Разрабатывать жизненный цикл продукта и определять цели по времени.
2.1.5. Разрабатывать лидирующие технологии и интегрировать в концепцию продукта/услуги.
2.2. Разрабатывать, создавать и оценивать образцы продуктов или услуг.
2.2.1. Разрабатывать спецификации на продукты или услуги.
2.2.2. Осуществлять параллельное проектирование продукта.
2.2.3. Осуществлять расчет стоимости продукта.
2.2.4. Создавать конструкторскую документацию.
2.2.5. Разрабатывать образцы продуктов или услуг.
2.2.6. Оформлять патенты на продукт или услугу.
2.3. Совершенствовать существующие продукты или услуги.
2.3.1. Разрабатывать улучшения потребительских качеств продукта или услуги.
2.3.2. Устранять проблемы качества и надежности продукта или услуги.
2.3.3. Снимать с производства устаревшие продукты или услуги.
2.4. Оценивать эффективность новых или измененных продуктов/услуг.
2.4.1. Осуществлять подготовку к производству.
2.4.2. Разрабатывать и анализировать процесс производства опытных образцов.
2.4.3. Обеспечивать необходимыми материалами и оборудованием.
2.4.4. Внедрять и анализировать новые процессы или методологии.
2.5. Управлять процессом разработки продукта/услуги.
3. Производство и поставка (для организаций, ориентированных на сервис).
3.1. Планировать и получать необходимые ресурсы.
3.l.l. Выбирать и сертифицировать поставщиков.
3.1.2. Приобретать материалы и комплектующие изделия.
3.1.3. Приобретать необходимые технологии.
3.2. Разрабатывать требования к квалификации персонала.
3.2.1. Определять требования к квалификации персонала.
3.2.2. Выявлять необходимость проведения тренингов.
3.2.3. Осуществлять мониторинг и управление повышением квалификации.
3.3. Оказывать услуги потребителю.
3.3.1. Подтверждать специальные требования по обслуживанию конкретного потребителя.
3.3.2. Идентифицировать и планировать ресурсы для удовлетворения требований по обслуживанию.
3.3.3. Обеспечивать обслуживание специальных клиентов.
3.4. Обеспечивать качество обслуживания.
4. Управлять финансовыми и материальными ресурсами.
4.1. Управлять финансовыми ресурсами.
4.1.1. Разрабатывать бюджеты.
4.1.2. Управлять распределением ресурсов.
4.1.3. Определять структуру капитала.
4.1.4. Управлять потоками денежных средств.
4.1.5. Управлять финансовыми рисками.
4.2. Осуществлять финансовые и учетные операции (транзакции).
4.2.1. Работать с дебиторской задолженностью.
4.2.2. Осуществлять оплату труда персонала.
4.2.3. Работать с кредиторской задолженностью, кредитами и инкассо.
4.2.4. Вести бухгалтерский учет.
4.2.5. Выплачивать премии и пособия.
4.2.6. Управлять общехозяйственными и представительскими расходами.
4.3. Формировать отчеты.
4.3.1. Обеспечивать руководителей внешней финансовой информацией.
4.3.2. Обеспечивать руководителей внутренней финансовой информацией.
4.4. Проводить внутренний аудит.
4.5. Управлять налогами.
4.5.1. Обеспечивать соответствие законодательству.
4.5.2. Планировать налоговую стратегию.
4.5.3. Выбирать эффективные технологии.
4.5.4. Управлять налоговыми спорами.
4.5.5. Информировать руководство о налогах.
4.5.6. Управлять налогами.
4.6. Управлять материальными ресурсами.
4.6.1. Управлять планированием капитала.
4.6.2. Приобретать и продавать основные средства.
4.6.3. Управлять оборудованием.
4.6.4. Управлять материальными рисками.
5. Производить продукцию и обеспечивать производство ресурсами.
5.1. Планировать и получать необходимые ресурсы.
5.1.1. Выбирать и сертифицировать поставщиков.
5.1.2. Приобретать основные средства.
5.1.3. Приобретать материалы и комплектующие изделия.
5.1.4. Приобретать требуемые технологии.
5.2. Преобразовывать ресурсы (входы) в продукты.
5.2.1. Разрабатывать и настраивать процесс производства (для существующего процесса).
5.2.2. Разрабатывать график производства.
5.2.3. Перемещать материалы или ресурсы.
5.2.4. Изготавливать продукт.
5.2.5. Упаковывать продукт.
5.2.6. Складировать или хранить продукт.
5.2.7. Подготавливать продукт к поставке.
5.3. Поставлять продукт.
5.3.1. Планировать поставку продукта.
5.3.2. Поставлять продукт потребителю.
5.3.3. Устанавливать продукт.
5.3.4. Обеспечивать специальные требования потребителя.
5.3.5. Идентифицировать и планировать ресурсы для удовлетворения требований по обслуживанию.
5.3.6. Обеспечивать обслуживание клиентов.
5.4. Управлять процессом производства и поставки.
5.4.1. Документировать и осуществлять мониторинг статуса заказов.
5.4.2. Управлять запасами.
5.4.3. Обеспечивать качество продукта.
5.4.4. Планировать и выполнять текущий ремонт.
5.4.5. Осуществлять мониторинг внешних условий.
Первый шаг построения моделей – определение внешних входов и выходов организации. В первую очередь рабочая группа выделяет входы и выходы, связанные с основной деятельностью организации, обычно это набор входных и выходных документов, формируемых для внутренних нужд и отчетов перед вышестоящими организациями или партнерами.
После определения входов и выходов составляется предварительный перечень бизнес-процессов верхнего уровня (бизнес-процесс сбыта готовой продукции, бизнес-процесс снабжения, бизнес-процесс производства готовой продукции и т.п.), после чего осуществляется распределение функций по процессам. Эта ответственная работа выполняется на основе результатов изучения предметной области и носит субъективный характер.
Субъективность распределения функций по процессам может привести к противоречиям при дальнейшей работе с моделями: кто отвечает за процесс в целом, кому целесообразно делегировать те или иные функции, как распределена ответственность и т.д. При отображении бизнес-процессов верхнего уровня необходимо использовать функции одного уровня.
Для представления этих результатов предварительного исследования бизнес-процессов в виде графической модели необходимо руководствоваться следующими правилами:
· ограниченное количество функций на схеме (не более шести-восьми);
· все функции должны быть одного уровня;
· на схеме должна быть отображена информация по управлению процессом;
· все функции должны быть привязаны к подразделениям.
Так, например, процесс «закупки» состоит из пяти основных групп функций: функции планирования закупок, функции планирования заказов, функции получения, хранения и отпуска в производство, функции оплаты и функции бухгалтерского учета операций по закупкам [27].
Верхний уровень описания бизнес-процессов соответствует процессам, управляемым заместителями руководителя организации. Примером верхнего уровня может быть процесс закупки сырья и материалов для производства, который включает такие работы, как планирование закупок, заключение договоров, оформление заказов, получение товароматериальных ценностей (ТМЦ), оплата ТМЦ, отпуск ТМЦ в производство.
Второй уровень декомпозиции рекомендуется рассматривать на уровне процессов крупных подразделений предприятия.
Третий уровень – это уровень функций подразделений и отделов, четвертый уровень – операции, выполняемые на рабочих местах и т.д.
Декомпозиция функций выполняется до тех пор, пока каждая функция нижнего уровня декомпозиции может быть реализована одним программным модулем.
При моделировании бизнес-процессов очень важно определить их содержание, то есть из каких функций должен состоять конкретный бизнес-процесс. Особенно это важно на этапе построения моделей «TO BE», но и на этапе построения модели «AS IS» следует также ориентироваться на процессный подход к управлению [27]. Признаком бизнес-процесса можно считать наличие в его составе пяти основных элементов: планирование и осуществление деятельности, регистрация фактической информации, контроль и анализ, принятие решений.
При правильном построении модели все функции, выполняемые в подразделениях, будут распределены по бизнес-процессам. Полученная модель «AS IS» содержит все имеющиеся недостатки в организации деятельности предприятия: выявляются неуправляемые работы, работы не обеспеченные ресурсами, ненужные и неэффективные работы, дублирующие работы и т.д.
Если построить информационную систему, базируясь на функциональной модели «AS IS», то будет реализована автоматизация предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли». Такой подход недопустим, поскольку подобная ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. Обычно и модель данных не строится для модели «AS IS».
7 .2. 2 . Построение модели “TO BE”
При построении модели «TO BE» следует также максимально удовлетворять требованиям процессного подхода к управлению: правильно определять состав функций каждого бизнес-процесса на нижних уровнях иерархии. Выходом каждого бизнес-процесса должен воспользоваться хотя бы один клиент, необходимо максимально сократить количество подразделений, поскольку большинство проблем возникает на границах между подразделениями организации. Для этого надо либо заранее описать действия на всех этапах бизнес-процесса, либо изменить структуру подразделений, либо изменить поток работ.
Однако основным инструментом при построении модели «TO BE» является Business process reengineering ( BPR ) - это радикальный способ реконструкции управления деятельностью предприятия. Цель BPR - добиться более гибкой реакции предприятия на изменения требований потребителей или на прогноз таких изменений при снижении затрат всех видов.
Реинжиниринг изменяет реконструируемые бизнес-процессы следующим образом.
1. Несколько рабочих процедур объединяются в одну. Для перепроектированных процессов характерно отсутствие технологии «конвейера», в рамках которой на каждом рабочем месте выполняются простые задания или рабочие процедуры. Теперь они интегрируются в одну – происходит горизонтальное сжатие процесса. Если не удается привести все шаги процесса к одной работе, то создается команда, отвечающая за данный процесс. Горизонтальное сжатие ускоряет выполнение процесса примерно в десять раз.
2. Исполнители принимают самостоятельные решения. В ходе реинжиниринга осуществляется не только горизонтальное, но и вертикальное сжатие процессов. Это происходит за счет самостоятельного принятия решения исполнителем в тех случаях, когда при традиционной организации работ он должен был обращаться к управленческой иерархии. Наделение сотрудников большими полномочиями и увеличение роли каждого из них в работе приводит к значительному повышению их отдачи.
3. Шаги процесса выполняются в естественном порядке. Реинжиниринг процессов освобождает от линейного упорядочивания рабочих процедур, позволяя распараллеливать процессы там, где это возможно.
4. Процессы имеют различные варианты исполнения. Новые процессы, в отличие от традиционных, ясны и просты – каждый вариант ориентирован только на одну соответствующую ему ситуацию.
5. Работа выполняется в том месте, где это целесообразно. В традиционных компаниях она организуется по функциональным подразделениям: отдел заказов, транспортный отдел и т.п. Реинжиниринг распределяет работу между границами подразделений, устраняя излишнюю интеграцию, что приводит к повышению эффективности процесса в целом.
6. Уменьшается количество проверок и управляющих воздействий. Задача реинжиниринга – сократить их до экономически целесообразного уровня. Вместо проверки каждого из выполняемых заданий перепроектированный процесс часто агрегирует эти задания и осуществляет проверки и управляющие воздействия в отложенном режиме, что заметно сокращает время и стоимость процессов.
7. Минимизируется количество согласований. Задача реинжиниринга состоит в минимизации согласований путем сокращения внешних точек контакта. Речь идет о стирании граней между функциональными подразделениями.
8. «Уполномоченный» менеджер обеспечивает единую точку контакта. Механизм «уполномоченного» менеджера применяется в тех случаях, когда шаги процесса либо сложны, либо распределены таким образом, что их не удается объединить силами небольшой команды. «Уполномоченный» менеджер играет роль буфера между сложным процессом и заказчиком.
9. Преобладает смешанный централизованно-децентрализованный подход. Современные технологии позволяют действовать полностью автономно на уровне подразделений, сохраняя при этом возможность, пользоваться централизованными данными
Задачи, которые приходится решать в ходе реинжиниринга, обычно характеризуются высокой степенью сложности и большой ответственностью.
На основе этих положений BPR создается модель «TO BE». Рассмотрим построение модели «ТО ВЕ» на примере управления городом, используя для этого стилизованные диаграммы потоков данных «объектного» типа.
На рис. 7.12 представлена модель управления городом «AS IS», при которой весь груз проблем по обеспечению своей жизнедеятельности (поиск поставщиков, закупка оборудования и материалов, оплата коммунальных услуг, выплата зарплаты и пр.) несут на себе бюджетные учреждения: школы, больницы, детские сады и т.п. При этом все эти действия выполняются неквалифицированными специалистами, которые не всегда правильно ориентируются в выборе поставщиков, качественного оборудования и товаров, а также возможны всевозможные финансовые нарушения и махинации.
Рис. 7.12. Модель управления городом «AS IS»
Модель управления «ТО ВЕ» финансовыми и материальными потоками муниципального образования построена по принципу корпорации, в которой централизован ряд финансово-хозяйственных процедур (рис. 7.13).
В этой модели служба закупок, собрав заявки от муниципальных учреждений города, например на приобретение мебели и компьютеров, осуществляет крупные централизованные закупки, которые могут оказаться значительно выгоднее за счет объема и конкурсного отбора поставщиков. Закупками занимается узкий круг подготовленных специалистов, возможность различного рода нарушений существенно уменьшается. При этом учреждения освобождаются от составления всевозможных отчетов о закупках и потраченных средствах.
Переход на единую схему муниципальных закупок дает экономию в 15-20 %, автоматизация учета расходов местного бюджета может принести до 20 % экономии.
Рис. 7.13. Модель управления городом «TO BE»
Данный пример является типичной задачей бизнес-анализа, для которой широко применяются методологии IDEF0, IDEF3 и DFD.
Как правило, создают несколько моделей «TO BE», а затем на основе расчетов выбирают одну оптимальную, которая является основой для создания будущей ИС: она определяет состав функций системы, является основой для построения логической базы данных и пользовательского интерфейса.
Пример пользовательского интерфейса представлен на рис. 7.14-7.16.
Рис. 7.14. Форма «Сведения о пациентах», выбор «Справка»
Рис. 7.15. Стартовая форма ИС кардиологического
терапевтического отделения
Рис. 7.16. Форма «Меню заведующего», выбор «Особый режим»
В отличие от рассмотренного выше подхода, когда функциональная модель строится «сверху-вниз», рядом авторов, проповедующих процессный подход, предлагается выстраивать модель «снизу-вверх», чтобы максимально эффективно реализовать основные процессы [14]. В этом случае происходит не распределение функций (дробить можно бесконечно), а объединение (заведомо конечное).
Тогда функциональная модель выстраивается самым оптимальным образом для конкретного бизнеса. Группировка функций у конкретных работников получается наиболее естественной, рациональной и, следовательно, эффективной, а их должностные инструкции становятся работоспособными, практичными.
Однако этот подход может иметь место для небольших предприятий, когда количество функций нижнего уровня иерархии незначительно и с ними со всеми можно работать одновременно. Для крупных предприятий этот подход можно использовать на этапе построения модели «TO BE» для модификации и перегруппировки функций нижнего уровня иерархии в составе родительских функциональных блоков.
Библиографический список
· Альбитов А. Классификация гостеприимства. PC WEEK/RE, 2001. № 45.
· Ахтырченко К.В., Леонтьев В.В. Распределенные объектные технологии в информационных системах. СУБД, 1997. № 5-6.
· Бирюков В., Дрожжинов В. Введение в CRM. PC WEEK/RE, 2001. № 25.
· Бобровский С. Программная инженерия развивается экстремальными методами. PC WEEK/RE, 2001. № 35.
· Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. М.: Гелиос АРВ, 2002. 368 с.
· Горчинская О.Е. Designer/2000 – новое поколение CASE-продуктов фирмы Oracle. СУБД, 1995. № 3.
· Гулько Д. В2В: Корпоративные системы электронного снабжения в нефтегазовой отрасли. PC WEEK/RE, 2002. № 13.
· Гулько Д. В2В: промышленность движется к Hi-Tech. PC WEEK/RE, 2001. № 10.
· Зиндер Е.З. Соотнесение и использование организации жизненных циклов систем. СУБД, 1997. № 3. С. 41-53.
· Интеграция данных об изделии на основе CALS-технологий. Государственный межведомственный научно-исследовательский и образовательный центр CALS-технологий. Москва, 2001.
· Кальянов Г.Н. CASE: структурный системный анализ (автоматизация и применение). М.: Изд. Лори, 1996. 242 с.
· Колетски П., Дорси П. Oracle Designer. Настольная книга пользователя. Изд. Лори, 1999. 592 с.
· Корнеев И.К. Информационные технологии в управлении. М.: ИНФРА-М, 2001. 160 с.
· Королев В.А. Основа повышения эффективности бизнеса// Методы менеджмента качества. 2004. № 10. С. 24-28.
· Липаев В.В. Мобильность программ и данных в открытых информационных системах. М.: Науч.кн., 1997. 368 с.
· Липаев В.В. Системное проектирование сложных программных средств для информационных систем. М.: СИНТЕГ, 2002. 258 с.
· Липаев В.В. Стандарты, регламентирующие жизненный цикл сложных комплексов программ информационных систем// Электронный журнал «Инженерное образование». 2005. № 8.
· Липаев В.В. Формирование и применение профилей открытых систем// Открытые системы. 1997. № 5.
· Макарычев П.П. Методологии и технологии проектирования систем. Пенза, ПГУ. 2004.
· Маклаков В.С. Создание информационных систем с All Fusion Modeling Suite. М.: ДИАЛОГ-МИФИ, 2003. 432 с.
· Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. М.: ДИАЛОГ-МИФИ, 2001. 256 с.
· Милаев В.В. и др. Автоматизация управления в условиях многономенклатурного мелкосерийного производства. PC WEEK/RE. 2001. № 10.
· Минаси М. Графический интерфейс пользователя. Секреты проектирования. М.: Мир, 1996. 159 с.
· Ойхман Е.Г. Реинжиниринг бизнеса: реинжиниринг организаций и информационные технологии. М.: Финансы и статистика,1997. 334 с.
· Петров В.Н. Информационные системы. СПб.: Питер, 2003. 687 с.
· Попов Э.Н., Шапот Н.Д. Реинжиниринг бизнес-процессов и информационные технологии// Открытые системы. 1996. № 1 (15).
· Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. М.: РКА «Стандарты и качество», 2005. 408 с.
· Савицкий Н.И. Технология организации, хранения и обработки данных. М.: ИНФРА-М, 2001. 232 с.
· Смирнова Г.Н. Проектирование экономических информационных систем. Учебник для вузов. М.: Финансы и статистика, 2002. 512 с.
· Смирнова В.В. Динамическое моделирование экономики. Учебное пособие. М.: Маркетинг, 2001. 32 с.
· Судов Е.В. Интегрированная поддержка жизненного цикла машиностроительной продукции. М.: ООО Издательский дом «МВМ», 2003. 264 с.
· Трофимов С. Заказчики знают, чего хотят// Сетевой журнал. 2004. № 10.
· Урман С. Oracle 8: Программирование на языке PL/SQL. М.: Лори, 1999. 607 с.
· Чеботарев В. Моделирование бизнеса: средства и методы. PC WEEK/RE. 2000. № 9.
· Шарашов К. Автоматизация крупных предприятий. PC WEEK/RE. 1997. № 6.
· Шубанов С. Как заставить CRM приносить прибыль? //Журнал «Логинфо». 2005. № 3.
· Яфуров А. Внедрение КИС: подводные камни проектов. PC WEEK/RE. 2004. № 15.
CОДЕРЖАНИЕ
| Введение………………………………………………………………. | 3 |
| Глава 1. Стратегия CALS и компьютерные системы для ее реализации…………………………………………………………………… | 5 |
| 1. Стратегия СALS как средство повышения конкурентоспособности предприятий………………………………………… | 5 |
| 1.2. CALS-технологии…………………………………………. | 7 |
| 1.3. Компьютерные системы для реализации CALS-технологий……………………………………………………………. | 10 |
| 1.4. Кто и какую выбирает ИС для автоматизации предприятия……………………………………………………………………. | 15 |
| 1.5. Как разрабатывают и внедряют ИС……………………… | 18 |
| Глава 2. Технологии проектирования и технологическая зрелость предприятий-разработчиков ИС………………………...................... | 22 |
| 2.1. Общие сведения о технологии проектирования………… | 22 |
| 2.2. Модели жизненного цикла ИС…………………………… | 24 |
| 2.3. Технология проектирования на базе комплекса российских стандартов ГОСТ 34……………………………………………. | 27 |
| 2.4. Методология фирмы Oracle - Custom Development Method (CDM) ……………………………………………………....... | 30 |
| 2.4.1. Процессы ЖЦ модели classic в CDM………....... | 30 |
| 2.4.2. Этапы ЖЦ модели classic в CDM………………. | 33 |
| 2.4.3. Обзорная диаграмма этапа определения требований (стратегия) модели classic CDM……………………………... | 34 |
| 2.4.4. Обзорное представление этапа определения требований модели classic CDM……………………………………. |
37 | ||
| 2.5. Общие понятия о методе управления проектом заказной разработки PJM……………………………………………………….. |
39 | ||
| 2.6. Методология Microsoft Solutions Framework…………. ... | 41 | ||
| 2.6.1. Три модели MSF…………………………………. | 41 | ||
| 2.6.2. Технология и инструменты разработки решений…………………………………………………………………….. |
51 | ||
| 2.7. Методология экстремального программирования……… | 54 | ||
| 2.7.1. Общие сведения об экстремальных методологиях…. | 54 | ||
| 2.7.2. Экстремальное программирование (ХР)………... | 56 | ||
| 2.8. Понятие технологической зрелости предприятия-разработчика ИС……………………………………………………… |
59 | ||
| Глава 3. Сравнительный анализ стандартов на организацию жизненного цикла создания и использования ИС. Профили стандартов…………………………………………………………………….... |
62 | ||
| 3.1. Методология Oracle CDM……………………………....... | 65 | ||
| 3.2. Международный стандарт ISO/IEC 12207:1995-08-01. Процессы ЖЦ программного обеспечения…………………………. |
66 | ||
| 3.3. Комплекс российских стандартов ГОСТ 34……………... | 68 | ||
| 3.4. Профили стандартов на разработку программных средств……………………………………………………………….… |
71 | ||
| 3.4.1. Общие сведения о профилях стандартов……….. | 71 | ||
| 3.4.2. Предложения по профилю стандартов на разработку программных средств ………………………………................ |
74 | ||
| 3.4.3. Структура и содержание документации на программные средства…………………………………………………… |
81 | ||
| Глава 4. Комплекс систем управления для реализации управленческого стандарта CSRP……………………………………………… |
87 | ||
| 4.1. Интегрированные системы управления предприятием……………………………………………………………………… |
87 | ||
| 4.2. Системы управления взаимоотношениями с клиентами (CRM-системы)……………………………………………………….. |
95 | ||
| 4.2.1. Общие сведения о проблеме автоматизации взаимоотношений с клиентами…………………………………………… |
95 | ||
| 4.2.2. Особенности проектирования CRM-систем…....... | 101 | ||
| 4.2.2.1. Выбор CRM-стратегии……………………. | 101 | ||
| 4.2.2.2. Выбор функций CRM-системы…………... | 107 | ||
| 4.3. Системы электронной коммерции типа В2В…………… | 110 | ||
| 4.3.1.Типы систем В2В…………………………………. | 110 | ||
| 4.3.2. Интеграция АСУ (ERP) и систем типа B2B……. | 113 | ||
| 4.3.3. Особенности разработки промышленных систем электронной коммерции типа В2В………………………………….. |
114 | ||
| Глава 5. Сравнительный анализ программных инструментариев и методологий описания функциональных и информационных моделей…………………………………………………………………… |
118 | ||
| 5.1. Анализ современных программных инструментариев для создания ИС…………………………………………………….. |
118 | ||
| 5.2. Методология IDEF0………………………………………. | 126 | ||
| 5.3. Методология IDEF3………………………………………. | 132 | ||
| 5.4. Методология DFD…………………………………………. | 135 | ||
| 5.5. Создание логического и физического уровней модели данных…………………………………………………………………. |
139 | ||
| 5.6. Связывание функциональной модели и модели данных……………………………………………………………………... |
145 | ||
| Глава 6. Реализация CASE-технологии в инструментальной среде Oracle Designer/2000………………………………………………….. |
147 | ||
| Глава 7. Реализация начальных этапов проектирования ИС (по ГОСТ 34)………………………………………………………………. |
154 | ||
| 7.1. Этап формирования требований к ИС ………………....... | 154 | ||
| 7.1.1. Реализация этапа на основе методологий пакета BPwin…………………………………………………………………… |
154 | ||
| 7.1.2. Реализация этапа на основе методологий пакета Oracle Designer/2000…………………………………………………... |
161 | ||
| 7.2. Этап разработки концепции ИС………………………….. | 167 | ||
| 7.2.1. Построение модели “AS IS”……………………… | 167 | ||
| 7.2.2. Построение модели “TO BE”…………………….. | 175 | ||
| Библиографический список…………….…………………………….. | 180 | ||
| Содержание……………………………………………………………. | 182 | ||
К о в а л е н к о Владимир Васильевич
Проектирование информационных систем
Редактор Е.В. Ипатова
Корректор С.В. Макушина
Подписано в печать Формат бумаги 60х84 1/16.
Бумага газетная. Печать трафаретная. Усл. печ. л. 11,5.
Уч.-изд. л. 11,5. Тираж 80 экз. Заказ
Рязанский государственный радиотехнический университет.
390005, Рязань, ул. Гагарина, 59/1.
Редакционно-издательский центр РГРТУ.
Дата добавления: 2019-07-17; просмотров: 137; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!