 |
Состав критериев сравнения
|
|
|
|
Это один из самых важных элементов работы по выбору. Здесь есть два момента, на которых необходимо остановиться подробнее.
Момент первый – необходима структурированность информации по критериям сравнения. Старайтесь разработать критерии таким образом, чтобы была возможность получить количественную характеристику степени удовлетворения ИС тому или иному критерию. Это позволит избежать субъективизма при оценке и сравнении.
Момент второй - необходимо выбрать методику комплексной оценки по этим критериям, например, назначение каждому из них весовых коэффициентов для проведения средневзвешенной оценки. О методике оценки будет рассказано чуть позже. Самое важное – определить, насколько тот или иной критерий ЗНАЧИМ для ВАШЕГО ПРЕДПРИЯТИЯ, насколько удовлетворение программного обеспечения тому или иному критерию позволит Вам достичь главного – ЦЕЛЕЙ проекта.
В процессе определения и обоснования критериев необходимо учитывать следующие основные требования:
- критерии должны быть между собой согласованными и непротиворечивыми. Показатели, используемые в качестве критериев оценки, не должны дублировать учет одних и тех же аспектов возможных действий;
- состав показателей оценки должен быть минимально достаточным и полным, соответствовать поставленным целям. При этом желательно, чтобы множество показателей оставалось настолько малым, насколько это возможно. С ростом числа показателей существенно снижается достоверность оценок и, как следствие, эффективность метода;
- значения критериев должны быть реальными и достижимыми.
Естественно, можно разработать общий для всех компаний перечень критериев сравнения, в большинстве случаев такой список и применяется. Приведём пример этого списка (заметим, что в него входят не обязательные, а наиболее часто используемые критерии). С другой стороны, список может быть, учитывая специфику конкретной компании, дополнен или изменён.
|
|
|
Итак, критерии сравнения:
Функциональность — это то, ради чего собственно продукт (информационную систему) и приобретают. Это та польза, те возможности, которые он предоставляет.
Поэтому если в системе нет важных для вашего предприятия функций и они не могут быть добавлены в разумные сроки (посредством настроек или относительно небольшого допрограммирования) – то и говорить не о чем, данная система предприятию не подходит.
Гораздо сложнее, когда формально система может "все". Ваше предприятие работает в конкретной стране, принадлежит к определенной отрасли, имеет свои индивидуальные особенности. Поэтому стоит задать такие вопросы:
· Насколько полно отражено в системе национальное законодательство (например, бухгалтерское, налоговое)? Какие используются методики расчета зарплаты? Соответствует ли порядок выполнения операций принятому на предприятиях данного типа? На каком языке приведены команды, написана документация? Понятна ли документация пользователям? Работает ли система на других отечественных предприятиях и каковы отзывы?
· Как учтены (или могут быть учтены) отраслевые особенности? Есть ли опыт применения в отрасли и каковы примеры?
· Каким образом может быть учтена специфика конкретного предприятия?
· Может ли система работать с территориально распределенными предприятиями (это важно для структур с удаленными подразделениями)? Если да, то возможна ли такая работа на слабых каналах связи?
· Интегрируется ли система с другими системами управления?
Говоря о возможностях учета тех или иных особенностей, важно понять, как это делается в системе практически. Существует несколько основных вариантов:
|
|
|
· все особенности уже учтены в системе и ничего делать не нужно;
· изменить систему невозможно (т.е. она не обладает свойством открытости, о котором говорится ниже);
· систему можно настроить посредством установления значений тех или иных параметров, что доступно прямо из программы;
· наконец, систему можно доработать на уровне исходного кода (допрограммировать с помощью специального или универсального языка программирования).
И мировая, и отечественная практика показывает, что системы реально внедряются с применением всех этих подходов. Другое дело, в каком соотношении они используются. Крайности здесь нежелательны - например, настройка сотен и тысяч параметров – дело непростое и достаточно дорогое (из-за "цены" соответствующих специалистов), а допрограммирование и перепрограммирование всякой мелочи означает необходимость иметь специализированных программистов или постоянно обращаться к разработчику. Если последний работает с Вами напрямую, это еще не является проблемой, но если речь идет о цепочке дилеров и прочих посредников, то ситуация, как правило, становится сложнее.
Опыт многих компаний показывает, что, по-видимому, оптимальным является «золотое правило»: около 60 % — вес настроек, а остальное (примерно 40 %) — доработка. «Коробочные» варианты применимы, как правило, либо для очень маленьких компаний, либо для очень узкой функциональности.
Масштабируемость. Можно рассматривать функциональную масштабируемость, т.е. возможность при необходимости приобрести или активировать дополнительные модули, которые не требуются на начальных этапах проекта по автоматизации, и масштабируемость по мощности, т.е. способности системы нормально функционировать и оперативно реагировать на действия пользователя при увеличении количества пользователей, количества обрабатываемых документов, росте объема существующих данных.
Технологичность. Это такие показатели как интегрированность (использование всеми модулями одной базы данных, однократный ввод данных и т.п.), интегрируемость (возможность автоматического, полуавтоматического и ручного обмена данными с существующими приложениями), открытость системы (возможность модификации функциональности продукта с помощью встроенных или внешних средств разработки, путем изменения исходных кодов функций и процедур, ядра системы, интерфейсных форм, структуры и модели данных и т.п.)
|
|
|
Инвариантность по отношению к бизнесу. Возможность поддержки системой разных видов бизнеса. Например, производства продуктов питания и оказания автотранспортных услуг. Этот критерий особенно важен для корпоративных структур с диверсифицированными видами деятельности.
Перспективы развития. Важно выяснить планы разработчиков в отношении развития и модификации продукта. Были случаи, когда проекты по дальнейшей разработке и поддержке программного обеспечения просто прекращались разработчиками и клиенты оставались один-на-один со своими проблемами по развитию проектов автоматизации.
На текущем этапе развития технологий наличие веб-интерфейса можно считать весьма положительным свойством. Помимо очевидных преимуществ - кроссплатформенности и доступности информационной системы из любой точки мира, только веб-интерфейс при росте количества пользователей позволяет безболезненно масштабировать систему и в сжатые сроки производить обновление функционала. Один из примеров - переход на новую версию ПО.
Поскольку после внедрения деятельность Вашего предприятия будет существенно зависеть от нормальной работы внедрённой системы, то большое значение имеет качество сопровождения и поддержки поставщиком внедренного ПО. Показателями уровня качества поддержки могут выступать:
-
Наличие у поставщика документарно-описанной политики по поддержке клиентов и тщательность проработки контракта на сопровождение и техническую поддержку; - Наличие у поставщика отдельного подразделения, занимающегося техническим сопровождением;
- Наличие специальных каналов связи (выделенные телефонные номера, адрес электронной почты, страницы в Интернет, посвященные именно поддержке);
- Наличие специализированного ПО для автоматизации процесса приема и обработки проблем, возникающих у клиентов.
Побывайте на предприятиях, где данная система уже работает. Посмотрите на все своими глазами. Найдите ответы на такие вопросы:
|
|
|
- Какие сертификаты качества есть у компании-поставщика?
- Есть ли у поставщика специализированные подразделения по внедрению и сопровождению?
- Существуют ли (формализованные) методики работ или все делается, как "бог на душу положит" (иногда последнее скрывают за фразами типа "индивидуальный подход" и т.п.)?
- Какие процедуры снижения рисков предусмотрены (опытная эксплуатация, "пилотные" проекты, устранение выявленных ошибок и т.д.)?
- Какова квалификация персонала компании-поставщика?
- Достаточна ли численность персонала?
- С вами будет работать непосредственно разработчик системы или посредник?
Существуют и другие, непротиворечащие данной, точки зрения на состав критериев сравнения, например, для многих компаний совсем нелишним будет учесть архитектуру системы и используемую СУБД.
|
|
|
