1. Выделить управленческие (производственные) задачи, для решения которых предприятию необходима информационная система. Разработать критерии оценки соответствия системы требованиям предприятия.
2. Выбрать методы оценки экономической эффективности системы, которые будет использовать предприятие, и рассчитать эффективность.
3. Определить, какие новые бизнес-процессы необходимо внедрить, и реинжиниринг каких существующих бизнес-процессов необходимо осуществить для максимально эффективного использования информационной системы.
4. Определить, варианты приобретения программного обеспечения информационной системы: приобретение готовой отечественной или зарубежной системы, адаптация базового варианта системы под специфику предприятия или самостоятельная разработка системы.
5. Принять решение о том, как использовать имеющиеся на предприятии программные средства и комплексы: интегрировать с внедряемой информационной системой или полностью отказываться от их использования.
Функциональные требования. Это документ или часть ТЗ
6. Установить правила, по которым будет осуществляться управление информационными потоками в новом режиме. Принять меры для снижения сопротивления персонала предприятия нововведениям.
В настоящее время на отечественных предприятиях авиационной промышленности, а также ее основных подотраслях самолетостроении, двигателестроении, приборостроении, агрегатостроении, ракетостроении, часто используется схема выбора информационной системы в соответствии с этапами, показанными в табл. 2.1. Анализ практического опыты внедрения информационных систем на предприятиях авиационной промышленности показывает, что этапы, представленные в табл. 2.1, не должны выполняться строго в данной последовательности, а некоторые из них могут выполняться параллельно.
В применяемых в настоящее время на практике методах выбора информационных систем сформулирован ряд требований к системам, которыми необходимо руководствоваться при их выборе. К ним относятся:
1. Интегрированность системы, которая заключается в том, что изменения показателей в одной ее части должны автоматически влиять на показатели в других взаимосвязанных частях.
2. Процедуры в информационных системах должны быть действительно автоматизированы. Не должно быть ситуаций, когда после внедрения системы, число процедур не уменьшается, а процедуры, до внедрения системы выполняемые на бумаге, после внедрения выполняются аналогично на компьютере.
3. Информационная система должна обеспечивать реализацию бизнес-процессов и процедур, которые существуют либо должны существовать, т.е. оптимальны для конкретного предприятия.
4. Информационная система должна давать руководителю возможность получать оперативную информацию в объеме, достаточном для принятия оперативных управленческих решений.
5. Информационная система должна быть легка в обучении и использовании, чтобы рядовой сотрудник мог научиться выполнять свои обязанности при ее помощи за максимально короткое время.
6. В информационной системе должна быть заложена возможность, без помощи программиста редактировать все необходимые отчеты и документы, менять их форму и создавать собственные форматы.
2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)
7. В информационной системе должны быть заложены процедуры контроля, сводящие ошибки к минимуму.
8. В информационной системе должна быть возможность журналирования операций, т.е. система должна давать возможность отследить, кто и когда внес изменения в том или ином файле, и какая запись была до этих изменений.
9. В информационной системе должны присутствовать надежные программы защиты данных и функции распределения прав доступа.
При разработке стратегии выбора информационной системы для предприятия авиационной промышленности, которые в последние два десятилетия функционируют в условиях жестких финансовых ограничений, чрезвычайно важно связать внешние факторы выбора с внутренними, например:
1. Бюджет проекта, который включает: цену проекта, показатель ROI (ROI – Return on Investments или возврат на вложенные инвестиции) и TCO (ТСО – Total Cost of Ownship или совокупная стоимость владения информационной системой).
2. Стратегия выбора информационной системы должна позволить минимизировать состав команды специалистов по выбору информационной системы со стороны предприятия и последующее сопровождение внутренними силами.
3. Дефицит временного ресурса не позволяет предприятиям авиационной промышленности реализовывать слишком длительные проекты, каким бы качественным не представлялся их конечный результат.
Важным мотивом при разработке стратегии выбора и внедрения информационной системы является личный интерес руководителей предприятия, руководителей фирмы-разработчика системы и спонсоров данного проекта. Кроме того, значение имеет личный интерес менеджеров предприятия, руководящих процессом выбора и последующего внедрения информационной системы. Участие в такого рода масштабных проектах может обеспечить им карьерный рост, усилить позиции на предприятии и принести ощутимые выгоды в системе внутрифирменной политики.
Однако в настоящее время при выборе управленческих информационных систем руководители предприятий авиационной промышленности часто не только не принимают участия в разработке стратегии выбора информационной системы, но практически никак не используют ее в своей работе, тем самым лишая себя и предприятие преимуществ, которые дает хорошая технология для повышения эффективности управления в части принятия адекватных управленческих решений. Часто информационная система остается средством автоматизации рутинного труда исполнителей, способом накопления данных, которые довольно часто потом никак не используются. Очень важно встроить внедряемую информационную систему в систему управления предприятием в целом, создать технологию принятия управленческих решений и корректирующих воздействий на базе различных информационных технологий.
При разработке стратегии выбора и внедрения информационной системы важно не упускать из виду множество различных и противоречивых интересов персонала внутри предприятия. Например, при выборе и внедрении информационной системы для предприятий авиационной промышленности необходимы минимальные сроки.
В этом заинтересованы руководители предприятия и ответственная часть среднего менеджмента. Однако в минимизации изменений в бизнес-процессах предприятия, полном отсутствии таких изменений или вообще отказе от внедрения системы заинтересована основная часть среднего менеджмента и, особенно, рядовых сотрудников. Кроме того, руководство предприятия заинтересовано в минимизации затрат на покупку, внедрение и эксплуатацию информационной системы. А менеджмент среднего звена предприятия, получающий мотивирующее вознаграждение от поставщика системы, заинтересован в максимизации мотивированных затрат на покупку и внедрение системы, а также ее эксплуатацию.
Руководством предприятия определяется место проекта по внедрению информационной системы в общей стратегии развития предприятия, последовательность автоматизации отдельных сегментов деятельности предприятия (видов деятельности, бизнес-процессов, структурных подразделений), требования к программному обеспечению информационной системы с учетом имеющих место ограничений, в том числе и финансовых.
Результаты анализа бизнес-процессов предприятия авиационной промышленности позволяет определить общие требования к информационной системе и выделить специфические особенности бизнеса конкретного предприятия. Именно эти особенности, как правило, и являются определяющим фактором при принятии решения о выборе той или иной информационной системы. Подготовленная с учетом общих и специфических требований спецификация информационной системы является основой при выборе конкретного программного продукта из имеющихся программ на рынке.
Разработка стратегии выбора информационной системы для предприятия авиационной промышленности напрямую зависит от методов управления, используемых на предприятии, которые в свою очередь зависят от типа производства. При разработке стратегии выбора и внедрения информационной системы учитываются также следующие факторы: виды деятельности предприятия; инициатор проекта и его значимость на предприятии; группы интересов внутри предприятия; группы влияния внутри предприятия; стиль руководства предприятием; морально-психологический климат на предприятии; организационно-штатная структура предприятия.
Автоматизация может быть с помощью готовой информационной системы, адаптированной под специфику предприятия и решаемых задач информационной системы, а также системы, разработанной на предприятии сотрудниками в области информационных технологий. Однако перед выбором направлений автоматизации выявленных систем или подсистем чаще всего проводится анализ и оценка готовых решений, представленных на отечественном рынке, формируется расширенный перечень таких решений, отвечающих общим целям развития предприятия. Кроме того, разрабатывается методика их сравнения, определяется процесс принятия решения (если предполагается выбор на основе тендера, определяются форма проведения тендера, состав конкурсных материалов, методика оценки предложений и т.п.). Одна из наиболее часто применяемых в настоящее время на предприятиях авиационной промышленности методик разработки стратегии выбора и внедрения информационной системы, состоит из трех этапов, которые представлены на рис. 2.1.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Как правильно сформировать требования к ИТ-системе
На примере рассказываем, каким образом можно формулировать требования, и показываем примеры документов, которые можно использовать при составлении требований. Статья будет полезна людям, которые пытаются разобраться в способах построения IT-инфраструктуры предприятия.
89 просмотров
За 7 лет разработки и внедрения индивидуальных IT-систем на нашей платформе Бипиум мы столкнулись с множеством крупных и не очень крупных предприятий. Каждое находилось на определенном этапе развития цифровой грамотности. Кто-то формулирует требования профессионально, у кого-то получается не очень профессионально. Мы хотим помочь вторым разобраться в теме и научить их понимать цель внедрения IT-системы.
Статья большая, поэтому держите оглавление:
- Что такое требования и для чего они нужны
- Как начать формулировать требования
- Выделение ролей и бизнес смысла ролей
- Выделение периферии — сторонние системы
- Что будет, если составить требования неправильно
- На чем не стоит зацикливаться
- Краткое резюме
Что такое требования и для чего они нужны
В понятие «требования к информационной системе» можно вложить несколько смыслов. Первое определение требований — комплексное описание того, как информационная система повлияет на работу компании. Второе определение требований — описание желаемого поведения системы при ее использовании участниками деятельности. Требования нужны, чтобы и вы, и разработчик системы понимали, что должно получиться в итоге.
Оба тезиса применимы к цифровизации уже существующей деятельности и цифровизации планируемой.
Бывают случаи, когда заказчик приходит на встречу с разработчиком не подготовив требования и начинает импровизировать. В таком случае получается хаотичный набор информации, из которого нельзя собрать что-то конкретное. Из-за этого, либо стоимость разработки увеличивается в разы, либо система не решает глобальную проблему.
Как начать формулировать требования
Рассмотрим на примере процесса заключения договора с клиентом.
Опишите контекст, в котором находится компания и автоматизируемую деятельность. Например, нужно описать, что в заключении договора несколько сотрудников выполняют определенные операции, что эти операции несут следующий бизнес смысл, который объединяется в определенный результат.
Используя наш пример с заключением договора, можно описать следующее:
«Наша компания занимается производством молочной продукции. Для реализации продукции мы заключаем договоры с оптовыми покупателями. У нас большое количество потенциальных покупателей, отдел продаж слишком долго формирует и подписывает договоры.
Автоматизируемая деятельность выглядит следующим образом: менеджер формирует и подписывает с заказчиком договор, передает договор в бухгалтерию для выставления счета».
Осмыслите проблемы, которые заставили вас думать об автоматизации. Это могут быть как конкретные кейсы, так и описание того, что затрудняет работу.
«Первая проблема — менеджеры не используют актуальный шаблон договора, потому что нет единого места, где хранится такой шаблон. Из-за этого наша компания может понести финансовые убытки.
Вторая проблема — менеджеры долго формируют данный договор, подставляя данные во все нужные поля.
Третья проблема — договоры долго доходят до бухгалтерии, из-за этого процесс получения денег сильно затягивается.
Четвертая проблема — менеджеры приходят/звонят в бухгалтерию, чтобы уточнить статус договора и денег, а это отвлекает бухгалтеров и сильно замедляет работу».
Сформулируйте цель создания системы. Система может регламентировать деятельность, сократить время на подготовку документов или что-то иное.
«Мы хотим организовать учет всех договоров, чтобы они не терялись.
Технические требования к информационной системе
При формировании технического задания в нем обязательно должны перечисляться все требования к информационной системе, в противном случае разработчик просто не будет знать, для какой цели создается продукт, что он предназначен выполнять и каким образом. Задача формулирования требований ложится на заказчика, хотя на практике с этим обычно помогают менеджеры, через которых происходит оформление заказ. А вот студенты, занимающиеся написанием курсовых, дипломных работ, должны самостоятельно уметь составлять такие списки.
Общее понимание вопроса
Процесс создание ИС достаточно сложный, состоит из множества последовательных этапов. Специалисты, работая над проектом, вынуждены разбираться с разнообразными сложностями. В некоторой степени упростить это можно точным формулированием требований к информационной системе. Не всегда очевидно, по каким причинам возникают проблемы, особенно при работе над инновационными продуктами, да и создание всеобъемлющего описания всех действий, для исполнения которых предназначен продукт, нередко представляет собой непростую задачу.
Внимание всем деталям
Полноценное представление о функциональных возможностях продукта – это и есть полный список требований к информационной системе. Включает он и аспекты, которые предполагает заказчик, а программист реализует при создании проекта. Процесс формирования возможностей, их аналитическое исследование, документирование, тестирование работоспособности – это разработка требований, в ходе которой удается точно выявить все ограничения и прийти к консенсусу между «хочется» и «реально осуществимо». При этом важно помнить, что современные инженеры – не волшебники, а лица, пользующиеся доступным техническим инструментарием, возможности которого, к сожалению, пока также ограничены. Не менее значим и аспект времени, так как работы по созданию, реализации требований предполагают существенные временные затраты – месяцы, а иногда годы.
Какие бывают?
Принято говорить о системных и пользовательских требованиях к информационной системе. Естественным языком описываются те, которые предъявляет конкретный пользователь. Для пояснения формулировок можно прибегать к диаграммам разной степени сложности. Это позволяет составить общее впечатление о функциях, для реализации которых предназначена ИС, и ограничениях, с которыми придется столкнуться в работе.
Системные требования – это такие специфические характеристики проекта, знание которых позволяет воплотить в реальность пожелания клиента. Эти технические требования к информационной системе включают в себя преставление об особенностях оборудования, его мощности, а также выбор в пользу конкретного варианта архитектуры. К системным можно отнести и многие другие аспекты, неочевидные для пользователя, но регламентирующие, каким будет конечный продукт.
Требования: откуда их взять?
Задачи формулирования и утверждения требований к информационной системе не столь просты, как это может показаться на первый взгляд. Термином принято обозначать такой сложный структурированный процесс, в рамках которого создается, подтверждается заказчиком, исполнителем документация, четко регламентирующая все спецификации продукта. Разработка подразделяется на четыре последовательных шага:
- аналитическая деятельность для определения степени реализуемости запланированного;
- создание, аналитическое изучение непосредственно требований;
- формулировка требований для формирования сопроводительной документации;
- аттестация требований к данным информационной системы, а также прочих условий, правил реализации проекта.
Не все так однозначно
Если единожды установлены требования к безопасности информационных систем, информационному наполнению, формату, управленческим задачам и прочим аспектам функционирования проекта, это еще не значит, что таковые будут неизменными до самого «победного конца». Рабочий процесс нередко сопровождается изменением установленных спецификаций, требований. Происходит это не только по инициативе заказчика, но и исполнителя, сталкивающегося с определенными техническими ограничениями, не допускающими воплощения в жизнь ряда запланированных аспектов. Важно учитывать особенности контроля процессов. Управление изменениями – это один из ключевых аспектов разработки требований и их реализации в рамках конкретной ИС.
Важный аспект работы с требованиями – определение таковых с последующей разносторонней аналитикой информации. Для этого применяют обобщенную модель работы. В рамках конкретного предприятия реализуется уникальная система управления требованиями информационных систем, позволяющая формулировать, корректировать, принимать, отвергать выбранные условия. Многое зависит от квалификации работников, типа ИС, над которой работают, применяемых в рабочем процессе стандартов.
Как это выглядит?
На практике формулировка, аналитика требований к безопасности информационных систем, наполнению данными, структуре (и прочие системные и пользовательские) предполагают сперва выявление особенностей конкретной предметной области. Ее исследуют квалифицированные аналитики, определяя специфические параметры сектора применения разрабатываемого продукта в будущем. После этого начинают собрать предварительные требования, работая с формулирующими таковую информацию лицами. Параллельно продолжают трудиться над уточнением предметной области.
Следующий шаг формулировки требований к муниципальным информационным системам, частным, применяемым в госорганах – создание иерархической системы выявленной информации. Если первоначальный сбор сведений дает хаотичный комплекс данных, то в рамках систематизации его упорядочивают, создавая группы элементов, имеющих меж собой логические связи.
Продолжая работу
Следующий шаг конкретизации требований к информации в информационных системах, структуре проекта, функциональным, внутренним особенностям – выявление противоречий и устранение конфликтов. Когда от широкого спектра третьих лиц получают сведения о работе проектируемой ИС, сталкиваются со следующей проблемой: каждый человек имеет собственные уникальные представления о возможностях проекта, его предназначении. Нередко полученные от разных лиц представления вступают в конфликт друг с другом, а также противоречат логике, имеющимся техническим возможностям, посредством которых система воплощается в жизнь. Чтобы упорядочить ситуацию, необходимо после тщательного анализа выявить все противоречия и найти оптимальное компромиссное решение для их устранения.
Выявляя противоречия и анализируя реализуемость всех требований, необходимо также составить систему приоритетов. Всегда среди общего набора требований есть более важные и менее значимые. Задача разработчиков – тесное сотрудничество с теми, кто создает требования, чтобы выявить, какие из установленных аспектов функционирования продукта самые значимые, а какие могут подождать или вовсе отмениться, если этому будут способствовать негативные внешние условия (например, нехватка времени). Создав систему приоритетов, можно приступать к проверке выявленных аспектов на полноту, сочетаемость между собой, последовательность.
Шаг за шагом
Требования к информационным системам (персональных данных, сведений о работе предприятия и любых других) формулируются в рамках циклического процесса. Все этапы связаны как напрямую, так и обратной взаимосвязью.
Шаги описаны выше: сперва необходимо выявить особенности предметной области, затем постепенно дойти до шага определения сочетаемости требований между собой, а также их полноты и прочих параметров, позволяющих говорить о применимости для разработчиков полученных условий на практике. Если удается создать полноценную картину предметной области, уже она задает условия работы, особенности функционирования. Повторение цикла дает более точное, глубокое представление об области, третий цикл позволит сформулировать требования еще четче. Повторения необходимы, пока все участники рабочего процесса не уяснят точно, для чего система предназначена и как будет работать, что необходимо воплотить при работе над проектом.
Чтобы процесс формирования требований был эффективным, а его результаты – применимыми в работе, необходимо следовать общепринятым алгоритмам формулировки условий.
Опорные точки зрения
Это базовый метод выявления требований к государственным информационным системам, частным – словом, абсолютно любым, вне зависимости от места их применения. В рамках определения условий необходимо в качестве начального условия признать, что точки зрения на рассматриваемый вопрос могут отличаться. Их выявляют и используют как базовые для формулировки сперва процесса сбора требований, а затем и собственно условий.
Точка зрения – довольно расплывчатое понятие, поэтому было разработано несколько подходов, трактующих его по-разному. Наиболее простая расшифровка понятия – источник данных, описывающих, как будет работать ИС. Опорные точки становятся базой для моделирования ИС и использования в рамках продукта информации. Сбор требований предполагает выявление всех значимых опорных точек, далее используемых в процессе построения продукта. При этом также учитывается, как методики будут применяться для обработки данных.
Альтернативный подход
Еще одна трактовка понятия «точка зрения» предполагает восприятие термина как структуры представления. Фактически речь идет об элементе модели продукта. Различные точки зрения позволяют создать многочисленные модели конечных автоматов, взаимодействия сущностей и связей между ними в рамках конкретного проекта. Учитывается специфика области применения проекта.
Точка зрения может означать мнение внешнего получателя сервиса, реализованного через ИС. На основании ТЗ можно выявить данные, которые используются при воплощении сервисов системы, управлении таковыми. Этот подход принято считать самым эффективным. Он лег в основу Viewpoint-Oriented Requirements Definition – специфического метода выявления требований, позволяющего определять информацию и эффективно анализировать ее.
Работа с точками зрения
Сперва их нужно идентифицировать, а также определить все сервисы, находящиеся в связи с конкретной точкой. Затем систему структурируют иерархическим образом, группируя точки зрения меж собой, выявляя общие для ИС сервисы. Таковые причисляют к самому высокому иерархическому уровню. Они будут наследоваться всеми ТЗ более низкого уровня.
Опорные ТЗ нужно задокументировать. Для этого информацию четко описывают, учитывая результаты идентификации. После этого можно составлять систему ТЗ, в которой будут отражены все объекты ИС, выявленные из собранной информации.
Не торопиться!
Как правило, работа над ИС начинается с масштабного мозгового штурма, призванного определить все возможные требования к проекту. Необходимо заранее осознавать, что одной процедурой определить все возможные требования практически нереально. Чем сложнее система, тем более количество таких процедур потребуется. Только если повторные мозговые штурмы с участием как заказчика, так и исполнителя, не дают полезной информации, обоснованно предполагают, что опорные ТЗ выявлены и требования сформулированы, можно приступать к их реализации техническими средствами.
Аттестация требований
Это процедура позволяет понять, в какой степени требования соответствуют представлениям заказчика о конечном продукте. Проверка – один из важнейших этапов, позволяющих обнаружить ошибочность спецификации и устранить ее заранее. В противном случае переделку придется вести на этапе, когда система уже спроектирована и сконструирована, что сопряжено и с временными, и с другими ресурсными потерями. Наибольшие проблемы приносят ошибки, обнаруженные уже после внедрения продукта на предприятии.
В общем случае работы по внесению корректировок в систему оцениваются значительно выше, нежели обнаружение и исправление неточностей на шаге проектирования ИС, кодирования функциональности. Изменение требований в большинстве случаев провоцирует внушительные структурные перемены, включая базовый уровень. Это означает, что после внесения изменений придется пройти полный комплекс поверок, тестирования, чтобы удостовериться в корректном функционировании всех спроектированных инструментов.
Источник: businessman.ru