eng
Рассматривается обследование предприятия как первый этап консалтинга при разработке и внедрении интеллектуализированных информационных систем, направленных на оказание поддержки инженерам предприятия при принятии ими решений в области конструкторско-технологической подготовки производства. Описывается содержание типовых задач, решаемых на этом этапе.
УДК 658.511 | ВАК 05.27.06
DOI: 10.22184/1992-4178.2018.175.4.128.130
УДК 658.511 | ВАК 05.27.06
DOI: 10.22184/1992-4178.2018.175.4.128.130
Теги: consulting enterprise information space enterprise information system optimization of business processes survey system integrator информационная система предприятия информационное пространство предприятия консалтинг обследование оптимизация бизнес-процессов системный интегратор
Данной статьей Группа компаний SWR начинает цикл публикаций, посвященных консалтингу при разработке и внедрении интеллектуализированных информационных систем, направленных на оказание поддержки инженерам предприятия при принятии ими решений в области конструкторско-технологической подготовки производства.
ТРЕБОВАНИЯ К ИЗДЕЛИЯМ И СОВРЕМЕННОЕ СОСТОЯНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Современное изделие – это наукоемкое и сверхтехнологичное устройство, которое для сохранения конкурентоспособности на рынке должно удовлетворять множеству требований, список которых растет с каждым годом. Некоторые из них становятся всё жестче, а к уже ставшим традиционными требованиям к массе, габаритам, надежности, экологичности, быстродействию, точности, эргономичности добавляются другие самые разнообразные функциональные требования.[1]
Если в прошлом для создания некоего нового изделия требовался год работы коллектива из сотни специалистов, то сейчас, следуя тенденции к повышению эффективности и минимизации затрат, с этим могут справиться небольшое конструкторское бюро и опытное производство в объеме цеха за несколько месяцев, несмотря на увеличение сложности изделий. Такой прогресс был бы невозможен без информационных технологий и специализированных интеллектуальных инструментов. То, что еще несколько десятилетий назад мы видели только в научно-фантастических фильмах и сериалах, сейчас стало обыденностью благодаря труду инженеров и внедрению таких инструментов.
Количество классов инструментов и систем на сегодняшний день превысило отметку десяти, а число наименований как свободного, так и проприетарного программного обеспечения (ПО) составляет несколько сотен. Подобные инструменты нацелены на решение узкого спектра задач и работают в рамках изначально заложенных в них разработчиками ограничений. Эти ограничения существуют как для отдельного программного продукта, так и для семейства продуктов или платформы. Один продукт хорош там, где другой применять совершенно недопустимо.
К данным ограничениям относятся возможности ядра системы, форматы и технологии управления данными (хранение, обмен), технологии совместной работы, поддержка новых версий и т. д. И это только технические ограничения конкретной реализации. Помимо них существуют и лицензионные, и региональные ограничения, связанные с поддержкой нормативной базы.
Обычно на предприятии существует определенный информационный ландшафт, сформировавшийся за годы его существования. Он определяется историей предприятия и его спецификой. Этот ландшафт может иметь неоптимальную структуру и каждый год устаревать. Таким образом, наряду с основными задачами по разработке и выпуску продукции, на предприятие ложится еще и обязанность по отслеживанию состояния внутренней ИТ-инфраструктуры в части, относящейся к процессам разработки изделий.
Нередки случаи, когда архитектура информационной системы была построена неправильно и требует перестроения для обеспечения эффективности решения возложенных на нее задач при реализации бизнес-процессов, либо возникает бизнес-потребность, которую имеющаяся система уже не способна удовлетворить.
БИЗНЕС-ЗАДАЧИ ПРЕДПРИЯТИЯ
Основной целью любого предприятия является выпуск продукции заданного качества в кратчайшие сроки и с минимальными издержками. Исходя из этого, предприятие сталкивается с задачами постоянной оптимизации внутренних бизнес-процессов для сокращения времени их выполнения, стандартизации и унификации применяемых технологий и конструкторских решений, создания и поддержки единой, сквозной по предприятию базы справочной информации, организации рабочего информационного пространства и т. д.
Для решения этих задач необходимы определенные компетенции, а также выполнение большого объема исследований, которые, в том числе, включают выбор программных решений и поиск наилучшей методологии, объединяющей ПО, мировые практики и процессы.
РОЛЬ СИСТЕМНОГО ИНТЕГРАТОРА
Если собственных ресурсов и компетенций, имеющихся у предприятия, недостаточно, оно обращается к системному интегратору, который помогает ему снизить затраты путем консалтинга на экспертном уровне. Он обеспечивает корректное взаимодействие между множеством программных модулей для достижения наибольшей эффективности работы, выстраивает систему из набора разрозненных приложений.
Создаваемая в результате система объединяет в себе:
• программные средства как совокупность программ обработки данных;
• кадровые ресурсы, а именно группы администрирования и пользователей;
• проектные процессы, направленные на управление выполнением работ, его контроль и регулирование;
• автоматизированные процессы, такие как поисковые (поиска данных), производственные (создания данных), информационные (использования имеющихся данных);
• информационное обеспечение пользователей системы в виде справочников и стандартов;
• методическое обеспечение в виде ролевых инструкций и общей методологии работы в системе;
• организационное обеспечение в виде регламентирующей документации.
Наличие всех указанных пунктов делает систему «живой», то есть самоорганизующейся, воспроизводящейся при вовлечении новых сотрудников, взаимодействующей с окружающими системами и требующей минимального контроля. Игнорирование же хотя бы одного компонента влечет к ее саморазрушению, пусть даже и отсроченному. В данной статье намеренно не упоминается конкретный класс или наименование ПО, поскольку приведенные соображения справедливы для любой системы независимо от ее сложности или архитектуры. Однако всё это ждет только в самом конце процесса внедрения.
Если рассмотреть жизненный цикл системы в целом как программного обеспечения, в нем можно выделить ряд этапов:
• этап формирования требований, определения потребностей заказчика в функциональных возможностях системы;
• этап разработки описания для создаваемой системы, то есть фиксация требований и определение архитектуры;
• этап опытной эксплуатации, а именно развертывание и тестирование системы в рамках базового функционала;
• этап масштабирования системы от объема пилотного проекта до окончательного объема и ее подготовки к работе на всех планируемых рабочих местах;
• этап промышленной эксплуатации, гарантийного и послегарантийного сопровождения, модульного развития.
ОБСЛЕДОВАНИЕ
В данной статье мы хотели бы уделить основное внимание именно первому этапу создания на предприятии комплексной информационной системы, поскольку именно на этом этапе осуществляется планирование всего проекта и допущенная ошибка приобретает очень большой вес ближе к концу процесса его реализации.
Любая система должна создаваться исходя из конкретной цели и обязана решать поставленные перед ней задачи, поэтому в начале любой разработки, любого внедрения всегда стоит бизнес-потребность. По сути, бизнес-потребность – это ответ на вопрос «зачем нужны организационные изменения?». Но вообще говоря, это ответ, рождающий дополнительные вопросы.
Первый из них: «Какова цель?», или, иными словами, «Чего хочет добиться предприятие в результате изменений?» Достижение цели может быть рассчитано на долгосрочную перспективу, и тогда этот процесс разделяется на несколько задач, которые, так же как и цель, должны быть корректно сформулированы.
Второй вопрос – «Какие проблемы система должна решить или какие возможности предоставить?»
Наконец, последний вопрос звучит так: «Какой желаемый результат или выгоду должно получить предприятие в итоге?» Ответ на этот вопрос обязательно должен быть количественным.
Обозначенные вопросы являются внутренними для компании, но чтобы было легче на них ответить, целесообразно привлечь квалифицированных консультантов. Эти ответы также выступят в качестве исходной информации для начала обследования и подготовительных мероприятий.
Далее наступает одна из самых значимых фаз – собственно, обследование. У обследования есть несколько типовых задач, которые приводятся ниже.
Точечный анализ бизнес-процессов (совокупности действий или работ, направленных на создание ценностей, продуктов или услуг) предприятия, который позволяет оценить уровень автоматизации и определить целевое состояние.
Бизнес-потребность, как правило, является следствием того, что бизнес-процессы на предприятии частично или полностью отсутствуют, не определены или функционируют некорректно. Именно поэтому перед внедрением изменений необходимо определить, какие проблемы существуют, и выбрать наиболее оптимальный план перехода таким образом, чтобы изменения прошли безболезненно.
После анализа бизнес-процессов должна появиться ясность в отношении следующего:
• какие бизнес-процессы и в какой последовательности выполняются на предприятии;
• какие механизмы и инструменты применяются для выполнения каждого бизнес-процесса;
• что является входящими и исходящими данными для каждого бизнес-процесса;
• какими регламентами регулируются бизнес-процессы;
• с помощью каких показателей определяется эффективность выполнения бизнес-процесса;
• какие роли в бизнес-процессе играют подразделения предприятия.
Также должны быть определены перечень и очередность проведения изменений.
Для выполнения анализа бизнес-процессов используется широкий спектр методик. Приведем несколько из них в качестве примера.
• Анализ проблем бизнес-процессов. На укрупненной модели бизнес-процессов выделяются проблемные зоны для определения возможных причин и их последующего устранения при реализации системы путем задания соответствующих требований.
• Ранжирование процессов по типам и степени важности. Эта методика позволяет определить порядок изменения процессов по приоритетам в ходе создания и внедрения системы.
• Бенчмаркинг или эталонное тестирование. Анализ процесса на основе существующих идеальных показателей.
• Анализ непрерывности процесса. Анализ разрывов в выполнении операций и передачи данных.
Анализ организационно-распорядительной документации – тщательное изучение документов, к которым могут относиться инструкции, регламенты, стандарты предприятия в области выполнения процессов, рабочая документация. Задачами данного анализа являются:
• определение объема изменений в регламентирующей документации: после внедрения системы ряд документов потребуется аннулировать, ряд изменить или создать;
• определение дополнительного контекста выполнения бизнес-процесса, то есть бизнес-правил, сущностей или атрибутов, влияющих на бизнес-процесс;
• определение требований.
Выполнение такого анализа позволяет лучше разобраться в сложившейся на предприятии ситуации.
Выявление и анализ требований – одна из самых сложных и ответственных задач наряду с анализом бизнес-процессов, поскольку требования определяют форму и вид будущей системы. Подзадачами для нее являются:
• Выявление бизнес-требований. Это высокоуровневые цели заказчика, которые напрямую коррелируют с бизнес-потребностью. В обозначенном выше вопросе о желаемом результате или выгоде предприятия в результате выполнения проекта в качестве ответа предполагался данный вид требований.
• Выявление функциональных требований. Данные требования определяют состав наименований и классов внедряемых программных средств системы, а также необходимые настройки и доработки. Функциональные требования опираются на бизнес-процессы.
• Выявление нефункциональных требований. Это атрибуты качества и ограничения системы, например масштабируемость, модульность, надежность и т. д.
Так же как и для анализа бизнес-процессов, для выполнения данной задачи существует ряд методик, таких как:
• Специфицирование требований. Сопоставление задачи и функций каждого требования, приоритезация.
• Анализ осуществимости требований. Требования должны быть правильно сформулированы, выполнимы и непротиворечивы.
Определение заинтересованных во внедрении сторон. Проект получит больше шансов стать успешным, если будет обеспечено необходимое взаимодействие с заинтересованными во внедрении сторонами. Заинтересованной стороной в контексте проекта является лицо, влияющее или способное влиять на достижение цели проекта. Основной задачей здесь является разработка или выбор правильной модели взаимодействия с заинтересованными сторонами, для чего требуется сначала их выявить, а затем классифицировать.
Выполнение приведенных задач позволяет сформировать окончательное представление о проекте и получить информацию для того, чтобы начать планирование его реализации.
ЗАКЛЮЧЕНИЕ
В данной статье был поднят вопрос важности начальной проработки проекта внедрения CAD / PDM / MES / ERP-систем в рамках обследования предприятия, а также описаны типовые задачи, выполняемые на данном этапе. В последующих статьях будут рассматриваться методологические подходы к выполнению других этапов внедрения данных систем. ●
ТРЕБОВАНИЯ К ИЗДЕЛИЯМ И СОВРЕМЕННОЕ СОСТОЯНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Современное изделие – это наукоемкое и сверхтехнологичное устройство, которое для сохранения конкурентоспособности на рынке должно удовлетворять множеству требований, список которых растет с каждым годом. Некоторые из них становятся всё жестче, а к уже ставшим традиционными требованиям к массе, габаритам, надежности, экологичности, быстродействию, точности, эргономичности добавляются другие самые разнообразные функциональные требования.[1]
Если в прошлом для создания некоего нового изделия требовался год работы коллектива из сотни специалистов, то сейчас, следуя тенденции к повышению эффективности и минимизации затрат, с этим могут справиться небольшое конструкторское бюро и опытное производство в объеме цеха за несколько месяцев, несмотря на увеличение сложности изделий. Такой прогресс был бы невозможен без информационных технологий и специализированных интеллектуальных инструментов. То, что еще несколько десятилетий назад мы видели только в научно-фантастических фильмах и сериалах, сейчас стало обыденностью благодаря труду инженеров и внедрению таких инструментов.
Количество классов инструментов и систем на сегодняшний день превысило отметку десяти, а число наименований как свободного, так и проприетарного программного обеспечения (ПО) составляет несколько сотен. Подобные инструменты нацелены на решение узкого спектра задач и работают в рамках изначально заложенных в них разработчиками ограничений. Эти ограничения существуют как для отдельного программного продукта, так и для семейства продуктов или платформы. Один продукт хорош там, где другой применять совершенно недопустимо.
К данным ограничениям относятся возможности ядра системы, форматы и технологии управления данными (хранение, обмен), технологии совместной работы, поддержка новых версий и т. д. И это только технические ограничения конкретной реализации. Помимо них существуют и лицензионные, и региональные ограничения, связанные с поддержкой нормативной базы.
Обычно на предприятии существует определенный информационный ландшафт, сформировавшийся за годы его существования. Он определяется историей предприятия и его спецификой. Этот ландшафт может иметь неоптимальную структуру и каждый год устаревать. Таким образом, наряду с основными задачами по разработке и выпуску продукции, на предприятие ложится еще и обязанность по отслеживанию состояния внутренней ИТ-инфраструктуры в части, относящейся к процессам разработки изделий.
Нередки случаи, когда архитектура информационной системы была построена неправильно и требует перестроения для обеспечения эффективности решения возложенных на нее задач при реализации бизнес-процессов, либо возникает бизнес-потребность, которую имеющаяся система уже не способна удовлетворить.
БИЗНЕС-ЗАДАЧИ ПРЕДПРИЯТИЯ
Основной целью любого предприятия является выпуск продукции заданного качества в кратчайшие сроки и с минимальными издержками. Исходя из этого, предприятие сталкивается с задачами постоянной оптимизации внутренних бизнес-процессов для сокращения времени их выполнения, стандартизации и унификации применяемых технологий и конструкторских решений, создания и поддержки единой, сквозной по предприятию базы справочной информации, организации рабочего информационного пространства и т. д.
Для решения этих задач необходимы определенные компетенции, а также выполнение большого объема исследований, которые, в том числе, включают выбор программных решений и поиск наилучшей методологии, объединяющей ПО, мировые практики и процессы.
РОЛЬ СИСТЕМНОГО ИНТЕГРАТОРА
Если собственных ресурсов и компетенций, имеющихся у предприятия, недостаточно, оно обращается к системному интегратору, который помогает ему снизить затраты путем консалтинга на экспертном уровне. Он обеспечивает корректное взаимодействие между множеством программных модулей для достижения наибольшей эффективности работы, выстраивает систему из набора разрозненных приложений.
Создаваемая в результате система объединяет в себе:
• программные средства как совокупность программ обработки данных;
• кадровые ресурсы, а именно группы администрирования и пользователей;
• проектные процессы, направленные на управление выполнением работ, его контроль и регулирование;
• автоматизированные процессы, такие как поисковые (поиска данных), производственные (создания данных), информационные (использования имеющихся данных);
• информационное обеспечение пользователей системы в виде справочников и стандартов;
• методическое обеспечение в виде ролевых инструкций и общей методологии работы в системе;
• организационное обеспечение в виде регламентирующей документации.
Наличие всех указанных пунктов делает систему «живой», то есть самоорганизующейся, воспроизводящейся при вовлечении новых сотрудников, взаимодействующей с окружающими системами и требующей минимального контроля. Игнорирование же хотя бы одного компонента влечет к ее саморазрушению, пусть даже и отсроченному. В данной статье намеренно не упоминается конкретный класс или наименование ПО, поскольку приведенные соображения справедливы для любой системы независимо от ее сложности или архитектуры. Однако всё это ждет только в самом конце процесса внедрения.
Если рассмотреть жизненный цикл системы в целом как программного обеспечения, в нем можно выделить ряд этапов:
• этап формирования требований, определения потребностей заказчика в функциональных возможностях системы;
• этап разработки описания для создаваемой системы, то есть фиксация требований и определение архитектуры;
• этап опытной эксплуатации, а именно развертывание и тестирование системы в рамках базового функционала;
• этап масштабирования системы от объема пилотного проекта до окончательного объема и ее подготовки к работе на всех планируемых рабочих местах;
• этап промышленной эксплуатации, гарантийного и послегарантийного сопровождения, модульного развития.
ОБСЛЕДОВАНИЕ
В данной статье мы хотели бы уделить основное внимание именно первому этапу создания на предприятии комплексной информационной системы, поскольку именно на этом этапе осуществляется планирование всего проекта и допущенная ошибка приобретает очень большой вес ближе к концу процесса его реализации.
Любая система должна создаваться исходя из конкретной цели и обязана решать поставленные перед ней задачи, поэтому в начале любой разработки, любого внедрения всегда стоит бизнес-потребность. По сути, бизнес-потребность – это ответ на вопрос «зачем нужны организационные изменения?». Но вообще говоря, это ответ, рождающий дополнительные вопросы.
Первый из них: «Какова цель?», или, иными словами, «Чего хочет добиться предприятие в результате изменений?» Достижение цели может быть рассчитано на долгосрочную перспективу, и тогда этот процесс разделяется на несколько задач, которые, так же как и цель, должны быть корректно сформулированы.
Второй вопрос – «Какие проблемы система должна решить или какие возможности предоставить?»
Наконец, последний вопрос звучит так: «Какой желаемый результат или выгоду должно получить предприятие в итоге?» Ответ на этот вопрос обязательно должен быть количественным.
Обозначенные вопросы являются внутренними для компании, но чтобы было легче на них ответить, целесообразно привлечь квалифицированных консультантов. Эти ответы также выступят в качестве исходной информации для начала обследования и подготовительных мероприятий.
Далее наступает одна из самых значимых фаз – собственно, обследование. У обследования есть несколько типовых задач, которые приводятся ниже.
Точечный анализ бизнес-процессов (совокупности действий или работ, направленных на создание ценностей, продуктов или услуг) предприятия, который позволяет оценить уровень автоматизации и определить целевое состояние.
Бизнес-потребность, как правило, является следствием того, что бизнес-процессы на предприятии частично или полностью отсутствуют, не определены или функционируют некорректно. Именно поэтому перед внедрением изменений необходимо определить, какие проблемы существуют, и выбрать наиболее оптимальный план перехода таким образом, чтобы изменения прошли безболезненно.
После анализа бизнес-процессов должна появиться ясность в отношении следующего:
• какие бизнес-процессы и в какой последовательности выполняются на предприятии;
• какие механизмы и инструменты применяются для выполнения каждого бизнес-процесса;
• что является входящими и исходящими данными для каждого бизнес-процесса;
• какими регламентами регулируются бизнес-процессы;
• с помощью каких показателей определяется эффективность выполнения бизнес-процесса;
• какие роли в бизнес-процессе играют подразделения предприятия.
Также должны быть определены перечень и очередность проведения изменений.
Для выполнения анализа бизнес-процессов используется широкий спектр методик. Приведем несколько из них в качестве примера.
• Анализ проблем бизнес-процессов. На укрупненной модели бизнес-процессов выделяются проблемные зоны для определения возможных причин и их последующего устранения при реализации системы путем задания соответствующих требований.
• Ранжирование процессов по типам и степени важности. Эта методика позволяет определить порядок изменения процессов по приоритетам в ходе создания и внедрения системы.
• Бенчмаркинг или эталонное тестирование. Анализ процесса на основе существующих идеальных показателей.
• Анализ непрерывности процесса. Анализ разрывов в выполнении операций и передачи данных.
Анализ организационно-распорядительной документации – тщательное изучение документов, к которым могут относиться инструкции, регламенты, стандарты предприятия в области выполнения процессов, рабочая документация. Задачами данного анализа являются:
• определение объема изменений в регламентирующей документации: после внедрения системы ряд документов потребуется аннулировать, ряд изменить или создать;
• определение дополнительного контекста выполнения бизнес-процесса, то есть бизнес-правил, сущностей или атрибутов, влияющих на бизнес-процесс;
• определение требований.
Выполнение такого анализа позволяет лучше разобраться в сложившейся на предприятии ситуации.
Выявление и анализ требований – одна из самых сложных и ответственных задач наряду с анализом бизнес-процессов, поскольку требования определяют форму и вид будущей системы. Подзадачами для нее являются:
• Выявление бизнес-требований. Это высокоуровневые цели заказчика, которые напрямую коррелируют с бизнес-потребностью. В обозначенном выше вопросе о желаемом результате или выгоде предприятия в результате выполнения проекта в качестве ответа предполагался данный вид требований.
• Выявление функциональных требований. Данные требования определяют состав наименований и классов внедряемых программных средств системы, а также необходимые настройки и доработки. Функциональные требования опираются на бизнес-процессы.
• Выявление нефункциональных требований. Это атрибуты качества и ограничения системы, например масштабируемость, модульность, надежность и т. д.
Так же как и для анализа бизнес-процессов, для выполнения данной задачи существует ряд методик, таких как:
• Специфицирование требований. Сопоставление задачи и функций каждого требования, приоритезация.
• Анализ осуществимости требований. Требования должны быть правильно сформулированы, выполнимы и непротиворечивы.
Определение заинтересованных во внедрении сторон. Проект получит больше шансов стать успешным, если будет обеспечено необходимое взаимодействие с заинтересованными во внедрении сторонами. Заинтересованной стороной в контексте проекта является лицо, влияющее или способное влиять на достижение цели проекта. Основной задачей здесь является разработка или выбор правильной модели взаимодействия с заинтересованными сторонами, для чего требуется сначала их выявить, а затем классифицировать.
Выполнение приведенных задач позволяет сформировать окончательное представление о проекте и получить информацию для того, чтобы начать планирование его реализации.
ЗАКЛЮЧЕНИЕ
В данной статье был поднят вопрос важности начальной проработки проекта внедрения CAD / PDM / MES / ERP-систем в рамках обследования предприятия, а также описаны типовые задачи, выполняемые на данном этапе. В последующих статьях будут рассматриваться методологические подходы к выполнению других этапов внедрения данных систем. ●
Отзывы читателей
