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

Требования к изделиям и современное состояние информационных систем

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

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

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

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

Бизнес-задачи предприятия

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

Роль системного интегратора

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

Если рассмотреть жизненный цикл системы в целом как программного обеспечения, в нем можно выделить ряд этапов:

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

Обследование

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

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

Второй вопрос – «какие проблемы система должна решить или какие возможности предоставить?»

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

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

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

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

После анализа бизнес-процессов должна появиться ясность в отношении следующего:

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

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

• Анализ проблем бизнес-процессов. На укрупненной модели бизнес-процессов выделяются проблемные зоны для определения возможных причин и их последующего устранения при реализации системы путем задания соответствующих требований.
• Ранжирование процессов по типам и степени важности. Эта методика позволяет определить порядок изменения процессов по приоритетам в ходе создания и внедрения системы.
• Бенчмаркинг или эталонное тестирование. Анализ процесса на основе существующих идеальных показателей.
• Анализ непрерывности процесса. Анализ разрывов в выполнении операций и передачи данных.

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

• определение объема изменений в регламентирующей документации: после внедрения системы ряд документов потребуется аннулировать, ряд изменить или создать;
• определение дополнительного контекста выполнения бизнес-процесса, то есть бизнес-правил, сущностей или атрибутов, влияющих на бизнес-процесс;
• определение требований.

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

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

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

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

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

Заключение