КОМПЬЮТЕР-ИНФОРМ Главная страница || Статьи ╧ 04'2002 || Новости СПб || Новости России || Новости мира
Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта
Наша газета регулярно предоставляет читателям сведения о новинках в сфере информационных и телекоммуникационных технологий. Это, если можно так выразиться, витрина магазина. А затем руководители отделов и специалисты соответствующих служб ╚примеряют╩ все сверкающее многообразие рынка к своим конкретным рабочим нуждам. И тут начинается самое сложное и интересное, выраженное народной мудростью в поговорке: ╚гладко было на бумаге┘╩. Поэтому периодически мы обращаемся к службам информатизации различных петербургских предприятий с просьбой поделиться их опытом решения реальных производственных и организационных задач посредством информационных технологий. Трудно переоценить пользу от подобных обменов опытом.
Понятно, что не каждое руководство захочет делиться своими проблемами: всегда хочется показать хороший результат, а не тернистый путь к истине. Но тут нам повезло: у нашей редакции сложились дружеские отношения с Управлением информационных систем (ИС) ОАО ╚Арсенал╩, и раз в год они любезно делятся с нами своими достижениями, решаемыми проблемами и задачами на будущее. На этот раз гл. редактор ╚КИ╩ Ольга Андронова присутствовала на совещании руководства и специалистов предприятия, Управления ИС и Технического Центра (ТЦ), посвященного реинжинирингу бизнес-процессов предприятия. Наверное, самой интересной для наших читателей была бы подробная стенограмма самого совещания. Но, по ряду причин, это вряд ли возможно. Поэтому мы подготовили отчет в виде интервью, задав вопросы руководству ОАО ╚Арсенал╩ и изложив последовательно точки зрения. Надеемся, что их опыт будет полезен и другим предприятиям и организациям СПб и России.
О.═Андронова,
В тексте обозначены инициалы тех, кто отвечал на отдельные вопросы. ≈ Примеч. ред.
Марк Яковлевич Железняк, руководитель ТЦ ≈ М.═Я.═Ж.
Сергей Борисович Королев, первый зам. ген. директора ОАО ╚Арсенал╩ ≈ С.═Б.═К.
Виктор Михайлович Кучерявых, нач. Управления ИС ≈ В.═М.═К.
В. На каком этапе находится создание корпоративной информационной системы предприятия?
О. (М.═Я.═Ж.) На совещании руководитель ТЦ М.═Я. Железняк представил результаты деятельности кросс-функциональной команды (КФК) по описанию бизнес-процессов разработки конструкторской и технологической документации и подготовки производства. В КФК вошли как сотрудники Управления ИС и ТЦ, так и производственных подразделений ╚Арсенала╩. Вся команда была разбита на подгруппы, каждая из которых занималась конкретно своим процессом. Перед ними была поставлена задача: разработать, организовать и внедрить реинжиниринг бизнес-процессов на базе ИТ. Участники КФК разработали математическую модель, а уже на ее основе составили описание бизнес-моделей и бизнес-процессов. Для описания был выбран стандарт IDEFO. Первые редакции описания БПР (бизнес-процессов) сразу высветили ╚узкие╩ места. Так, стала очевидной важная роль стандартов ≈ нормативных документов, имеющих юридическую силу на предприятии. КФК занялась изучением ситуации с нормативами, в том числе составлением перечня нужных (годных), негодных и отсутствующих.
По мере продвижения по бизнес-процессу, специалисты составили список вопросов, которые являются фундаментальными для решения той или иной задачи, и начали проверку их соответствия требуемому уровню. В результате руководство ОАО получило аналитический отчет по состоянию дел. М.═Я. Железняк последовательно проводил мысль о том, что чем детальнее будут ╚расписаны╩ функции и документы, тем лучше будут выбраны наиболее подходящие средства ≈ программные и аппаратные ≈ для внедрения ИТ-технологий.
На совещании активно обсуждались вопросы определения четких критериев эффективности бизнес-процессов и их взаимодействия. Большее внимание было уделено вопросу создания цикловых графиков (т.═е. дерева изделия, изображенного в виде объектов, которые в него входят) и реализации сетевого планирования на их основе с учетом потребных ресурсов. Один из выводов М.═Я. Железняка: необходимость создания единой плановой структуры на предприятии.
В.═М.═К. Сегодня на предприятии реализуется пилотный проект ╚Рабочее место конструктора и технолога╩. Причем принято, что управление КД (моделями, чертежами, текстовыми документами с версиями по изделиям) и маршрутные техпроцессы реализуются средствами PDM SmarTeam.
А для пооперационных техпроцессов рассматривается вариант интеграции с решениями минской фирмы ╚Интермех╩. Связь между уже установленной системой и решением ╚Интермех╩ осуществляется через API (прикладной интерфейс программирования). В настоящее время специалисты Управления ИС изучают порядок интегрирования и разнесения объектов по уровням: что оставить за SmarTeam, а что отнести на клиентское место в модули TechCard.
Что касается реализации корпоративной информационной системы предприятия, очень важно, что высшее руководство понимает класс ERP-систем, который нам нужен. Это должна быть интегрированная система. ИТ-менеджеру на западном предприятии класса ╚Арсенал╩ предлагается на выбор примерно 200 одинаковых по классу вариантов ERP-систем. В России существенно меньше, но тоже есть. Поэтому собственно выбор определяется наличием внешней команды у поставщика решения и ресурсами, согласованностью работы команды предприятия и команды внешней. Мы будем рассматривать различные варианты: и западные и отечественные системы.
В. Был ли создан единый план (проект) создания и внедрения КИС?
С.═Б.═К. Мы приняли год назад концепцию как машиностроительное предприятие, у которого на первом месте по важности стоит автоматизация процессов создания и работы с КД, т.═к. ОАО ╚Арсенал╩ специализируется по достаточно сложным изделиям. Все наши остальные процессы ≈ и производство, и деньги ≈ зависит от КД.
В. Выполнение каких бизнес-задач в первую очередь автоматизировалось (планируется автоматизировать) на предприятии?
В.═М.═К. Вообще говоря, автоматизация ≈ слово вредное. Автоматизировать ничего нельзя. Есть хороший совет: ничего не автоматизируйте ≈ уничтожайте.
(╚Реинжиниринг: не автоматизируйте ≈ уничтожайте╩, Майкл Хаммер. Harvard Business Review, July-August 1990. Статья была опубликована на сайте http://www.consulting.psi.ru.)
А если конкретно, то мы выработали концепцию, последовательность и сроки действия. К концу 2002 г. мы получим 10 рабочих мест под управлением PDM. У нас полный объем работы с КД ≈ начиная от создания чертежа, спецификации, текстового документа ≈ должен выполняться в среде PDM и интегрироваться с другими бизнес-процессами. Может оказаться, что не все 100═% деталей или сборочных единиц (ДСЕ) должны иметь модели, а только определенная часть ДСЕ собственного проектирования должна иметь трехмерные модели. Ну, например, для планочек или резиновых прокладок модели не нужны. А вот важные ДСЕ должны иметь модель, чертеж и спецификацию. Если нет необходимости в модели, мы управляем только чертежом и спецификацией.
В. Кто из руководства предприятия занимается вопросами информатизации?
С.═Б.═К. Вот все, кого вы здесь видели. То есть на уровне первого зам. ген. директора.
В. Что служит оценкой (качественной и/или количественной) степени выполнения задач по созданию КИС?
С.═Б.═К. Мне пока трудно сказать об окончательной оценке. Сегодня мы идем к решению. Хотелось бы идти быстрее.
В. Количественные оценки вы определяли для себя? Ведь любая автоматизация стоит денег.
С.═Б.═К. В оценках мы опираемся на собственный и мировой опыт. Количественных оценок по результатам у нас нет и пока не будет. Можно говорить более конкретно после внедрения первого этапа, когда мы сможем сказать, как увеличилась отдача от каждого конструктора и технолога. Сегодня мы оценивать не можем.
В. Ставилась ли задача оценки возврата инвестиций в КИС?
С.═Б.═К. Конечно. Но чтобы мы сегодня сказали, что через два месяца инвестиции должны вернуться ≈ такого у нас нет. Я понимаю, что завтра мы это не сделаем, но хотелось бы до конца года, чтобы первый этап по КД и ТД мы доделали. Что нам это дает? На мой взгляд, несколько вещей. В первую очередь, мы повышаем качество и сроки изготовления документации. Второе, это сокращение людских издержек, т.═е. трудоемкости производства. В процессе подготовки у меня автоматически останутся люди, которые хотят и могут работать, хотят научиться новому и смогут это новое принести на предприятие. Принести свое новое понимание конструкторско-технологических работ. Фонд заработной платы я не сокращу, а передам тем, кто останется. Соответственно, я получаю дополнительный резерв, чтобы стимулировать того, кто хочет работать и научится работать.
Надо понимать, что российские предприятия ВПК достаточно консервативны. Консервативная система работы с КД, обложенная со всех сторон всяческими нормативами и требованиями заказчика, в том числе и государства как военного заказчика. Соответственно, консервативны люди, которые с этой документацией работают и строят ее. И существуют длинные и очень затратные цепочки работы. А нам нужен кардинальный скачок в подходе к производству, в конечном варианте ≈ к нашей продукции. При сегодняшней системе формирования ценообразования люди привыкли, что чем больше затрачиваешь, тем лучше. Заплатят им по факту.
Зарплату сокращать нам уже некуда. Внедряя новые технологии, мы тратим большие деньги. Так что издержки сильно мы не сократим. Единственное, что нас подгоняет ≈ изделие сделать по-другому уже невозможно.
В. Насколько реинжиниринг бизнес-процессов на предприятии связан с внедрением информационных технологий?
С.═Б.═К. Теснейшим образом. Нельзя технологию, которая была, реализовать с применением ИТ. Они войдут в противоречие.
В. Проводилось ли предпроектное обследование предприятия?
В.═М.═К. Можно сказать и да, и нет. Сохранились данные тех времен, когда я, как руководитель темы, обследовал предприятие для разработки АСУП еще на ЕС ЭВМ. При сравнении с положением, сложившимся в последнее время, изменения выявляются не в лучшую сторону. Существовала логичная, строго организованная и прописанная в системе стандартов предприятия система технического документооборота. То, что было прописано в стандартах предприятия и документах и выполнялось ранее, стало рушиться за последние 15 лет. Обычно пишут как есть и как должно быть. А у нас ≈ как есть, как описано в документах, как должно было быть раньше, и нет того, как должно было бы быть сейчас. Причина такого положения дел заключается в прогрессе в области технологий. Проанализировав то, что было придумано специалистами ОАО ╚Арсенал╩ и отрасли при разработке системы документирования в свое время для ТПП, можно сказать ≈ замечательно. Это были очень умные люди, которые прописали строго в системе распределение функций между сотрудниками. И эта система была ориентирована на бумажные документы. А теперь получается, что если мы переходим к информационным технологиям, к другому виду носителя, то должна быть пересмотрена и технология. Единой системы под новую модель бизнес-процессов пока нет. Она попадает в состав проблем реинжиниринга.
В. Вы заказывали какие-либо обследования в последнее время?
В.═М.═К. Мы заказали специалистам из СПб ГТУ (Политехнического) аудит принятых нами вместе в ╚Би Питроном╩ решений в рамках проекта по PDM (см. ╚КИ╩ ╧ 1/2001). Я вообще считаю, что если есть два взгляда, то третий незаинтересованный ≈ не лишний. Третейский суд бывает весьма полезен. Мы ведь внедряем систему SmartSolutions. Но есть некоторая тонкость: реализуется не вариант, предлагаемый фирмой ╚Би Питрон╩. Они сделали универсальную для всех предприятий структуру классов объектов и предлагают ее всем, не настраивая на наши конкретные потребности. У нас, например, структура классов объектов существенно не изменилась. Это не значит, что у нас есть объекты, которых нет в варианте ╚Би Питрона╩. У нас просто другой вариант.
Специалисты ГТУ изучали нашу структуру конструкторской документации и идентификации КД, а также организацию процессов проектирования в КБ. Они готовят нам рекомендации по тому, что будет нужно переделать в связи с внедрением PDM.
В. А сейчас у вас после проведенного реинжиниринга бизнес-процессов везде используются ИТ?
С.═Б.═К. Нет, конечно. Ведь определенная часть функций обязательно сворачивается. Вот, к примеру, сидит контролер. Что он проверяет? Рамку, шрифты. Но если есть шаблон в CAD-приложении и пользователю не дано возможности его изменить, то функция нормоконтроля отмирает.
В. А после реинжиниринга останутся ли у вас такие рабочие места, до которых ИТ не дойдут?
С.═Б.═К. Нет. На самом деле мы сейчас идем двумя путями. Первый ≈ это реинжиниринг для создания систем, потому что мы поняли, что без описания процедур никакой автоматизации не будет. Второй путь ≈ мы идем от реинжиниринга бизнес-процессов в цехах, для улучшения эффективности работы подразделений. То есть совершенствуем то, что можно сделать уже сегодня, в нынешнем состоянии, без комплексной автоматизации. В рамках КТЦ мы осуществляем реинжиниринг бизнес-процессов под автоматизацию. Это то, что касается нашей стратегической идеи от конструкторской документации дойти, наконец, до потребителя.
Мы выбрали стратегическую задачу: идем от конструкторской документации к подготовке производства. И далее будет выстраиваться ERP-система, если нам удастся выполнить запланированное на этот год. Но мы понимаем, что это длительный процесс, поэтому сегодня часть работ в подразделениях автоматизируется локально, там, где информационные технологии уже можно применить. Это относится к бухгалтерии, кадровой службе, нормированию по видам работ.
Как только мы автоматизируем процесс изготовления КД и ТД, мы сможем планировать производство, входящие потоки металла и т.═п. Сегодня все это делается вручную, потому что номенклатура очень большая, каждую надо обсчитывать.
В. Что изменилось за год?
В.═М.═К. В прошлогоднем интервью я оценил отставание 2000═г. по темпам движения от 1999═г. В 2001═г. ≈ еще похуже. И причина этому ≈ люди. Это связано с тем, что изменения на предприятии ≈ не просто изменения в технологии, а социально-производственная структура. Это люди, их естественное нежелание изменений. Поэтому темпы, которые мы достигли в освоении трехмерного моделирования, на сегодня замедлились. Мне кажется, что это зависит от внедрения локальных мест. Если мы организуем работу в сети, с четким учетом ресурсов, то должно произойти ускорение.
В. Какие подсистемы САПР заработали на предприятии?
В.═М.═К. Есть рабочие места конструктора для моделирования деталей. Оно интегрировано с CAD-системой SolidWorks. Мы набираем функциональность клиентских мест для ТПП. То есть в опытной эксплуатации у нас все есть ≈ надо теперь ╚дотянуть╩ до потребителя. Вопрос только в железе и в кабеле.
В. Какая часть чертежей выполняется посредством САПР?
В.═М.═К. Не так много, как хотелось бы, но претензии к условиям вывода чертежей от подразделений КБ и ОГТ уже появились, и это показывает, что реальные плановые работы выполняются в среде САПР.
В. Используете ли вы Интернет при работе с заказчиками, партнерами и др?
В.═М.═К. Да. Кроме того, в 2002═г. я должен организовать технологический процесс передачи КД на машинном носителе═≈ модели, чертежи, спецификации ≈ от КБ-разработчика из Н.═Новгорода.
В. Какое количество сотрудников занимается задачами автоматизации?
В.═М.═К. В структуру правления ИС входит два отдела:
"═отдел ИТ ≈ 6 человек (КТС, Интернет и сайт, PDM);
"═отдел АСУ ≈ 4 человека (бухгалтерия и финансы, кадры, зарплата ≈ ТИС).
В ТЦ работает 5 человек, занимающихся описанием и реинжинирингом бизнес-процессов технической подготовки производства.
Всего АРМ в ОАО ╚Арсенал╩ около 200, развернуто 8 ЛВС. На АРМ установлена различная вычислительная техника ≈ для простых и очень продвинутых пользователей.
В структурных подразделениях есть ответственные за применение ИТ (КБ, ОГТ), производство СТО ≈ есть помощник директора по ИТ, ПДО ≈ зам. начальника.
В. Сколько человек на предприятии использует САПР, прочие автоматизированные подсистемы, АРМ?
В.═М.═К. САПР ≈ 7 человек прошли обучение, работающих в САПР ≈ 20-25 человек, ╚продвинутых╩ пользователей довольно много.
В. Рассматривалось ли какое-нибудь российское/зарубежное предприятие как образец в плане создания и использования КИС?
С.═Б.═К. Есть в Петербурге одно предприятие ≈ не буду его назвать. Они внедряли R/2, так и не внедрили. Теперь взялись за R/3. Мы к ней тоже присматривались и даже ездили в Германию. И пришли к выводу, что именно нам такого класса система и нужна. Мы не отказались от R/3 окончательно, но, поскольку у R/3 нет ни одной инсталляции на машиностроительных предприятиях России, мы будем рассматривать при выборе ERP-системы успехи именно на предприятиях, аналогичных ОАО ╚Арсенал╩. У SAP есть инсталляции на технологических предприятиях с непрерывными процессами, с конвейерами и при этом с достаточно ограниченным количеством процессов. А у нас достаточно сложные конструкции: в аппарате более 100 тыс. деталей. А сколько надо материалов, чтобы одну такую деталь сделать?
ERP-систему можно подбирать, ориентируясь на такой же класс предприятий, на такой же тип производства, на такой же размер. Это означает сходство системы проектирования и системы управления инженерными данными, поэтому нас и интересует система управления инженерными данными на предприятиях, которые выполняют аналогичные нам работы. Характеристики: единичный цикл, проектирование и изготовление на заказ сложной наукоемкой продукции с длительным циклом.
В. Проводится ли обмен опытом с руководством служб ИТ других предприятий?
В.═М.═К. По вопросам организации применения ИТ (конкретно, ПО PDM SmarTeam) в КБ в сентябре состоялось посещение английского предприятия Delphi Diesel, из предприятий СПб стоит отметить ОАО ЛМЗ и опыт работы с iMAN. Опыт предприятий и КБ судостроения мы перенимаем на полезной ежегодной научно-практической конференции, проводимой на ОАО ╚Северная верфь╩.
В Н.═Новгород ездили к партнеру ≈ КБ. В 2002 г. ╚Би Питрон╩ собирается организовать семинар пользователей SmarTeam.
Основным во всех этих поездках и контактах для нас является формулирование ключевых направлений применения ИТ при решении проблем ОАО ╚МЗ Арсенал╩.
В. Проводится ли обмен опытом с руководством служб других предприятий?
В.═М.═К. От случая к случаю, все держится на неформальных контактах. Считаю организацию обмена опытом ИТ-менеджеров очень полезной формой сотрудничества. Да и это интервью ≈ попытка показать, что мы делаем, в чем у нас проблемы и, соответственно, завязать контакты с руководством служб ИТ на аналогичных предприятиях. На мой взгляд, желательно создание Ассоциации ИТ-менеджеров СПб. Вашей редакции этим бы и заняться!
Краткое описание существующих методологий описания бизнес-процессов мы публикуем с любезного согласия Д.═А. Притыкина, преп. каф. теоретической механики МФТИ, автора статьи ╚BPwin 4.0: пришел, увидел, реорганизовал╩ (http://www.interface.ru/admail.asp?Url=/ca/bpwin4us.htm).
Существуют три методологии, позволяющие анализировать бизнес с трех ключевых точек зрения: IDEF0, DFD и IDEF3.
С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показываются информационные, людские и производственные ресурсы, потребляемые каждой работой.
С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В то же время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
С точки зрения последовательности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.
Рассмотрим эти методологии подробнее.
IDEF0 относится к семейству IDEF, которое появилось в конце 60-х гг. под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой, и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на 5 видов:
"═Стрелки входа (входят в левую грань работы) ≈ изображают данные или объекты, изменяемые в ходе выполнения работы.
"═Стрелки управления (входят в верхнюю грань работы) ≈ изображают правила и ограничения, согласно которым выполняется работа.
"═Стрелки выхода (выходят из правой грани работы) ≈ изображают данные или объекты, появляющиеся в результате выполнения работы.
"═Стрелки механизма (входят в нижнюю грань работы) ≈ изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы┘).
"═Стрелки вызова (выходят из нижней грани работы) √ изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.
Все работы и стрелки должны быть именованы. Первая диаграмма в иерархии диаграмм IDEF0 всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными. В контекст входит описание цели моделирования, области (описания того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точки зрения (позиции, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.
После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и поэтому досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).
DFD. Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота вашей организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
Всего DFD использует 4 важных элемента:
"═Работы. Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников
со скругленными углами.
"═Стрелки. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота.
"═Внешние ссылки. Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы.
"═Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных.
В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота. При этом часто выясняется, что существующие потоки информации, важные для деятельности компании, реализованы ненадежно и нуждаются в реорганизации.
IDEF3. Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии ≈ IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.
IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать ╚сеть переходных состояний объекта╩, предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.
С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец при закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, чтобы наглядно показать или лучше документировать бизнес-функции организации.
Модель, выполненная в IDEF3, может содержать следующие элементы:
"═Единицы работы (Unit of Work) ≈ основной компонент диаграммы IDEF3, близкий по смыслу к работе IDEF0.
"═Связи (Links) ≈ связи, изображаемые стрелками, показывают взаимоотношения работ.
В IDEF3 различают три типа связей:
≈ Связь предшествования (Precedence) ≈ показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.
≈ Связь отношения (Relational) ≈ показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.
≈ Поток объектов (Object Flow) ≈ показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.
Перекрестки (Junctions) ≈перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков:
≈ Перекресток слияния (Fan-in Junction) ≈ узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса.
≈ Перекресток ветвления (Fan-out Junction) ≈ узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.
"═Объекты ссылок (Referents)═≈ служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы.
Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов.
КОМПЬЮТЕР-ИНФОРМ Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка
Главная страница
Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл ╧ 77-4461 от 2 апреля 2021 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.
Телефон редакции (812) 118-6666, 118-6555.
Адрес: 196084, СПб, ул. Коли Томчака, д. 9
e-mail:
Для пресс-релизов и новостей