Анализ требований и другие техники выбора решений при автоматизации предприятий
В предыдущих главах был рассмотрен процесс АТ, как части процесса программной инженерии. Необходимо отметить, что АТ – достаточно специфичный процесс, знания о котором, даже полученные в рамках этого небольшого учебного курса, в полном объеме востребованы в первую очередь только в крупных компаниях-разработчиках программного обеспечения (в частности – АИС), которых в нашей стране, к сожалению, пока не так много. В заключительной главе обсуждается "другая сторона медали": возможность применения методов и техник АТ не со стороны разработчика информационных систем, а со стороны их заказчика. Это значительно расширяет сферу практической применимости изложенного материала: ведь АИС выбираются, заказываются и внедряются практически в каждом российском предприятии. Кроме того, в этом параграфе кратко рассмотрены и альтернативные техники, позволяющие осуществить осознанный выбор готового, либо заказного решения для автоматизации предприятий.
Современные тенденции в развитии АИС и технологий их создания
Индустрия производства АИС претерпела за 2 последних десятилетия качественные изменения. Это связано с такими тенденциями компьютерного мира и мировой экономики, как:
· развитием и появлением новой элементной базы;
· наступлением эпохи персональных компьютеров;
· появлением и развитием интегрированных сред разработки;
· появлением глобальных сетей передачи данных;
|
|
|
· глобализацией бизнеса;
· переходом к экономике, ориентированной на потребителя;
· появлением и развитием электронного бизнеса и др.
АИС прошли путь от однопользовательских систем к системам масштаба рабочей группы, малого предприятия, холдинга, транснациональной корпорации.
Среди современных тенденций в развитии технологий создания АИС следует отметить:
· быстрые методы прототипирования;
· ориентацию на варианты использования;
· переход от разработки к настройке.
Покупное или заказное ПО – критерии выбора
В мире IT существует определённая конкуренция между заказными и покупными системами. Основной аргумент сторонников заказных систем – "каждый серьёзный бизнес уникален и требует собственной разработки; универсализм – синоним бедности". Аргументы их противников – "количество типовых решений конечно и невелико. Одни и те же организационные решения работают в различных отраслях промышленности".
Существует значительное количество аргументов в пользу покупных систем, например:
1. ERP-система X разрабатывается вендором Y уже Z лет. За это время он освоил рынки крупнейших стран Запада, позади тысячи внедрений, что говорит о высоком качестве системы;
|
|
|
2. КИС базируется на референтной (эталонной) модели бизнеса. Данная модель апробирована на предприятиях десятков государств и отраслей промышленности, и помимо собственно системы вы (покупатель) получите подробные инструкции о том, как правильно вести бизнес и побеждать в конкурентной борьбе.
На порождение этих аргументов работают отделы маркетинга таких гигантов этого сегмента IT-индустрии, как SAP, Oracle, SAGE, Microsoft и др. И эти аргументы действительно и серьёзны, и убедительны. Тем не менее, несмотря на мощный прессинг лидеров производства КИС, по данным обзоров, соотношение заказных и покупных систем автоматизации предприятий в мире оценивается примерно как 50:50.
По сути, выбор осуществляется даже не из двух, а из трех вариантов:
1. закупить решение у вендора;
2. заказать эксклюзивное решение у фирмы-производителя прикладного программного обеспечения.
3. изготовить решение самостоятельно.
Основные критерии выбора:
· цена;
· степень уникальности бизнеса компании;
· уровень сервисного обслуживания.
Ценовые вопросы сводятся к анализу затрат на:
· закупку (или разработку);
· мероприятия по внедрению решения;
· владение (включая необходимые доработки).
|
|
|
Степень уникальности бизнеса компании характеризуется степенью отражения особенностей бизнеса компании в решениях, представленных на рынке.
Уровень сервисного обслуживания характеризуется наличием поддержки покупного программного обеспечения по месту размещения предприятия компании, политикой вендора (разработчика) в области поддержки, наличием горячей линии и т.п.
На практике зачастую используется комбинация 1 и 3 либо 2 и 3 вариантов: система закупается либо разрабатывается на стороне, внедряется, затем её сопровождение и развитие переходит к отделу автоматизации предприятия.
Стратегии выбора решения
Перед специалистом IT-отдела, либо независимым консультантом, которому поручен выбор решения в области автоматизации предприятия, стоит нелёгкая задача. Ведь на рынке представлены сотни решений в области автоматизации, и, чтобы хотя бы бегло ознакомиться с каждым из них, может потребоваться несколько человеко-лет.
На практике, конечно, вряд ли путь подробного изучения всех известных на рынке решений можно рассматривать всерьёз. В простейшем случае рассматриваются аналитические обзоры, подготовленные независимыми экспертами, оцениваются финансовые возможности предприятия внедрения и на третейский суд инвестора предоставляются 2-3 решения.
|
|
|
Чтобы сделать выбор обоснованным, используются стратегии выбора решения. Основные из них:
· анализ требований;
· анализ несоответствия;
· подход на основе "лучших практик".
Анализ требований
Рациональным приёмом, позволяющим снизить затраты на подготовку вариантов решения, а заодно снизить риски, является формирование документа требований (не только ко вновь создаваемому, но и к выбираемому продукту). Тем самым, часть работы можно переложить на представителей маркетинговых отделов вендоров – пусть они объяснят и продемонстрируют, как на практике реализуются Ваши требования.
Практическое применение методов анализа требований, рассмотренных в настоящем пособии, применительно к задаче выбора покупного решения, требует ответа на следующие вопросы:
· рамки проекта;
· широта анализа требований;
· глубина проработки требований;
· требуемые ресурсы.
Рамки проекта. Какие бизнес-процессы, подразделения, отделы предприятия необходимо автоматизировать? Практика внедрения ERP-систем показывает, что даже на самых передовых в информационном смысле предприятиях степень охвата бизнеса информационными технологиями редко превышает порог в 90%. Возможно, крупномасштабный проект автоматизации следует разбить на несколько этапов, начав, допустим, с планки в 30%. Другая стратегия – "всё и сразу" — предполагает попытку сразу выйти на максимально возможный охват функций.
Широта анализа требований. Сколько требований вы в состоянии сформулировать в течение разумного промежутка времени? Сколько времени уйдёт у вендоров на анализ документа требований, который вы подготовите? Д. О’Лири в [2] приводит следующий порядок: документ описания требований для предприятия с годовым оборотом в $40 млн. содержит около 1000 позиций (требований).
Глубина проработки требований. Какую выбрать степень детализации требований? Уровень документа "Концепция" вряд ли окажется достаточным для серьёзного рассмотрения. Необходимо отражать как функциональные, так и нефункциональные требования. Можно остановиться на кратких формулировках функций (лаконично, трудно проверяемо). Можно перейти на язык сценариев (появляется возможность доскональной проверки, но это потребует значительных ресурсов). Хорош вариант с комбинацией этих способов описания: критичный функционал описать в форме сценариев, остальное – в виде функций.
Требуемые ресурсы. Ключевой ресурс предприятия – человеческий ресурс. Найдут ли топ-менеджеры предприятия время на скрупулёзную оценку требований к системе? Насколько хорошо смогут сформировать требования руководители линейных подразделений? Насколько удастся задействовать ресурс поставщиков решений? Стоит ли привлекать внешних консультантов?
Какова цена обследования? Как быстро удастся сформировать требования? Какое время следует выделить на получение ответов от вендоров, на анализ этих ответов перед окончательным выбором?
Анализ несоответствия
Анализ несоответствия при выборе КИС базируется на классических методах бизнес-анализа, предполагающих построения моделей "как есть", "как надо" и переходной модели, показывающей путь реформирования предприятия [41].
Нюанс заключается в том, что в данном случае анализ "как есть" применяется не к бизнес-системе в чистом виде, а к её комбинации с имеющейся автоматизированной системой. Он призван высветить слабые стороны и имеющегося решения, и связанные с ним проблемы бизнеса.
Анализ "как надо" может производиться по одному из следующих сценариев: "реинжиниринга чистого листа" и "реинжиниринга, запускаемого технологией" [2].
В первом случае используются классические подходы к реинжинирингу предприятий [41,24] в комбинации с методами анализа и формирования требований.
Во втором случае речь идёт о реинжиниринге под конкретное ERP-решение. В этом случае основой для пересмотра действующих бизнес-процессов и уровня их автоматизации являются "лучшие практики", заложенные в соответствующей ERP-системе.
Как и в стратегии анализа требований, стратегия анализа несоответствия оставляет множество подводных камней и вопросов. Допустим, мы составили модель "надо" и рассматриваем спецификации конкурирующих ERP-систем. Как сопоставить эти два документа? Как измерить степень соответствия – по количеству функций? Где гарантии того, что функции, называющиеся одинаково в рассматриваемых документах, действительно одинаково работают?
Альтернативой рассмотренным выше стратегиям, позволяющей снизить степень неопределённости принятия решений, в определённой мере является подход на основе лучших практик [2].
Дата добавления: 2021-03-18; просмотров: 133; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!