Особенности задач выбора информационных платформ

ВВЕДЕНИЕ
ОПРЕДЕЛЕНИЯ
ВОПРОСЫ, ВОЗНИКАЮЩИЕ ПРИ ВНЕДРЕНИИ ИС.
ОСНОВНЫЕ ПРОБЛЕМЫ
Отсутствие постановки задачи менеджмента на предприятии
Необходимость в частичной реорганизация структуры и деятельности предприятия
Необходимость в изменении технологии работы с информацией, и принципов ведения бизнеса
Сопротивление сотрудников предприятия
Временное увеличение нагрузки на сотрудников при внедрении системы
Формирование квалифицированной группы внедрения и сопровождения системы, руководителя группы
ОПРЕДЕЛЕНИЕ ЦЕЛЕЙ ПРОЕКТА
СТАНДАРТЫ ИНФОРМАЦИОННОГО МЕНЕДЖМЕНТА.
ПРИНЦИПЫ ВЫБОРА ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ВЫВОД
ЛИТЕРАТУРА

Особенности задач выбора информационных платформ

Утверждение проектной методологии.
Обследование и реорганизация (в том случае, если она проводится) предприятия являются первым этапом проекта внедрения и их результаты определяющим образом влияют как на дальнейшую конфигурацию ИС, так и на соответствие результатов ожиданиям Заказчика. Поэтому уже на этом этапе всегда необходимо утверждать единую концепцию управления проектом и строго следовать ей на всех последующих стадиях, при необходимости внося в регламент коррективы, обусловленные новой предметной областью.
Как правило, любая проектная методология базируется на трех обязательных понятиях: модель команды, модель процессов и модель рисков. Модель команды определяет ролевой состав рабочей группы, правила взаимодействия между ролями и ответственность за выполнение проектных задач. Модель процессов описывает регламент выполнения работ, отчётную политику и правила предоставления результатов на протяжении всего жизненного цикла проекта. Модель рисков описывает правила выявления и отслеживания статусов рисков, а также принципы поиска решений по их устранению или плановому снижению последствий от их актуализации.
Управление проектом организационных изменений.
Утверждение модели команды, модели процессов и модели рисков.
Разработка и утверждение плана-графика обследования.
Управление проектом обследования. Построение и утверждение бизнес-модели «как есть». Представление и согласование полученных результатов.
Анализ бизнес-модели «как есть», разработка и утверждение бизнес-модели «как должно быть», планирование проекта реорганизации. Разработка технического задания на реорганизацию.
Управление проектом реорганизации бизнес-процессов и отдельных подсистем (например, системы мотивации) предприятия согласно техническому заданию.
Очень часто случается, что этим этапом пренебрегают и, в результате, автоматизация не даёт никаких ощутимых результатов. Внедрение ИС оправдано лишь в тех случаях, когда деятельность предприятия соответствует стратегии развития и все методы управления, лежащие в основе требований по функциональности ПО уже имеют свой утвержденный регламент. Другими словами, нет никакого смысла покупать программный модуль «Бюджетирование» и внедрять его, если сама система бюджетирования на предприятии отсутствует. То же самое можно сказать об оперативности обработки и доставки управленческой информации. Если в этом процессе возникают ситуации, когда задержки вызваны организационными проблемами, то и при наличии ИС требуемой полноты и актуальности информации добиться невозможно. Никогда не следует забывать о том, что если мы планируем внедрять ИС класса MRPII, то для начала нужно определиться с тем, как мы будем разрабатывать политику планирования производства с учетом новых условий, и уже потом разрабатывать техническое задание по конфигурации программного комплекса.
А самом деле, даже в тех случаях, когда поставщики ПО утверждают, что внедрение возможно по принципу «как есть», они лукавят, так как всегда наличие ИС подразумевает новые методы работы с информацией, а соответственно и новую бизнес-модель предприятия. Только в этом случае изменения будут продиктованы конфигурацией ПО, а не реальными показателями эффективности бизнес-процессов.
Реорганизация бизнес-процессов является отдельной и очень обширной темой, актуальность которой отразилась в создании целых научных школ, поэтому в контексте этой статьи мы не будем детально рассматривать разнообразие подходов к организационному проектированию.
 Утверждение новой бизнес-модели «как есть», соответствующей бизнес-процессам предприятия после осуществления реорганизации.
 Конкретизация целей и критериев успешности проекта построения ИС.
 Разработка функциональных и технических требований к ПО.
Выбор поставщика ПО
Формулирование требований к ПО (функциональность, открытость, развиваемость математической модели, технические требования, безопасность, интерфейс, документация, наличие успешно реализованных проектов).
Формулирование требований к поставщику ПО (политика ценообразования, форма контракта, принципы обслуживания и поддержки, кадровые возможности, финансовая стабильность).
Утверждение требований по форме и графику предоставления информации конкурсантами.
Разработка требований к форме презентации, подготовка контрольных примеров.
Рассылка тендерной документации и организация тендера. Выбор поставщика решения или принятие решения об индивидуальной разработке.
Определение формы сотрудничества и заключение контракта на поставку ПО.
Стандарты информационного менеджмента.
Программные комплексы, предназначенные для внедрения в качестве базиса информационных систем, обладают одним общим характерным свойством: они сложны для оперативного ознакомления. Эта проблема обусловлена следующими факторами:
Сложность не только внутренних механизмов работы, но и наблюдаемой функциональной структуры.
Большой набор специфических инструментов для различных областей менеджмента. Например, многие производственные и технологические тонкости неизвестны финансовому директору, и наоборот, главный инженер некомпетентен в принципах анализа финансовых отклонений. Специалист, принимающий решение по выбору программного комплекса, как правило, является IT-менеджером и имеет лишь общее и неполное представление об использующихся управленческих методиках.
Наличие специальной терминологии, большого количества стандартов и псевдостандартов информационного менеджмента (очень часто общие концепции называют стандартами или вообще ориентируются на «стандарты», являющиеся частью маркетинговой политики некоторых разработчиков).
Доступность материалов исключительно рекламного характера, фактическое отсутствие описания реального опыта использования программного комплекса и истинной статистики внедрений.
В качестве примера ниже приведены пять стандартных тезисов из маркетинговых брошюр разработчиков программных комплексов, а под ними расположена их трактовка, более соответствующая действительности или в большей степени отражающая информационное содержание.
«Наша система отвечает требованиям ERP-стандарта (класса)»
Программное обеспечение содержит функциональность, которая позволяет его использовать для построения комплексных информационных систем, включающих поддержку большинства направлений бизнеса (как минимум: управление финансами, управление производством и запасами и управление обслуживанием клиентов). Сразу необходимо уточнить, что ERP-стандарта (Enterprise Resource Planning) попросту не существует, и он относится к маркетинговым понятиям.
«Наша система отвечает требованиям стандарта MRPII»
В отличие от ERP, MRPII в некотором смысле является стандартом. Если выражаться точно, то MRPII (Manufactory Resource Planning) – это концепция управления производством и запасами, последняя её редакция (MRPII Standard System) была опубликована в 1989 г. американской ассоциацией управления производственными ресурсами APICS (http://www.apics.org/). Следует отметить, что концепция MRPII является методологией менеджмента, а не софтверным понятием, несмотря на то, что возможность её применения на крупных предприятиях стала реальностью с прогрессом в области информационных технологий.
Итак, принадлежность решения к классу MRPII должна означать функциональную поддержку программным обеспечением выполнения следующего цикла: «планирование заказов -> планирование потребности в сырье и материалах -> планирование производственных ресурсов -> контроль над исполнением производственной программы -> обратная связь».
Как показывает опыт, разработчики говорят о соответствии программного комплекса требованиям MRPII, когда существует какая-либо возможность планирования производственных ресурсов, а не только в тех случаях, когда поддерживается весь цикл. В первую очередь это касается отечественных софтверных компаний.
«Наша система является системой управления, а не системой учета»
Одно из самых спорных утверждений. Во-первых, программное обеспечение, как мы уже говорили, не является системой в рамках предприятия. И даже на базе самого продвинутого программного комплекса вполне можно построить систему, которая будет автоматизировать только бухгалтерский учёт. Но это только в качестве незначительного замечания.
Если смотреть глубже, нужно отметить, что основным управляющим фактором является процедура принятия решения, на основании результата которой осуществляется воздействие на систему (предприятие). ИС сама по себе решений не принимает, но, будучи эффективно настроенной, способна поставлять информацию руководителю в том ракурсе, который наиболее подходит для принятия конкретного решения. Вся информация (и плановая, и фактическая), которую формирует система в виде отчетов, составляется на основе учетных данных, поэтому говорить о разнице между «системами учета» и «системами управления» попросту бессмысленно.
Что касается использования на практике самого утверждения, то обычно программные комплексы считаются управленческими, если в них реализована функциональность для поддержки итеративной процедуры «планирование -> контроль -> анализ отклонений -> обратная связь».
«Наша система имеет многолетний опыт успешных внедрений на Западе и обладает самым большим набором отраслевых решений.»
Действительно, многие зарубежные ПО имеют солидный и позитивный опыт применения на Западе. Однако не стоит забывать, что сами по себе подходы к управлению в нашей стране и на Западе существенно различаются. Например, в большинстве экономически развитых стран существуют и широко применяются на практике отраслевые стандарты менеджмента. Тем самым, западные тиражируемые ПО, как правило, подразумевают наличие общего стандартного регламента управления деятельностью предприятий, при этом, позволяя (благодаря широким возможностям по настройке) учитывать все индивидуальные особенности. То же самое можно отнести и к понятию «отраслевое решение». Не секрет, что в СНГ (учитывая то, что соответствующий национальный менеджмент, как дисциплина, развивается чуть более 10 лет) практически не существует отраслевых управленческих стандартов (имеются в виду именно управленческие, а не технологические стандарты), и два предприятия, относящиеся к одной отрасли, могут принципиально различаться с точки зрения действующего управленческого регламента.
Несомненно, комплексные зарубежные решения применимы и у нас. Более того, при правильном подходе, их использование будет не менее продуктивным, чем на Западе. Однако, для того, чтобы их внедрение было успешным, всегда необходимо осуществлять реорганизацию бизнес-процессов, разрабатывать и утверждать регламент всех процедур и алгоритмов. Известно, что такой подход не является дешевым, однако ошибочно в целях экономии избегать его и вкладывать миллионы долларов в неэффективную информационную систему, пытаясь настроить подсистему производственного планирования в тех случаях, когда сама процедура планирования на предприятии не регламентирована и де-факто не существует.
«Наша система разработана в России и наиболее всего подходит для автоматизации отечественных предприятий»
Большинство отечественных ПО изначально проектировались, как индивидуальные системы учёта в рамках конкретного предприятия, силами отдела АСУ, в режиме дефицита ресурсов и в отсутствии какой-либо методологии управления разработкой. С этим и связано большинство их недостатков. В целом же, типичные «узкие места» отечественных ПО выглядят следующим образом:
Низкий уровень функциональности, интегрированности и недостаточное количество настроек.
Несовершенная математическая модель, негативно сказывающаяся на возможностях по развитию функциональности.
Нестабильность работы. Наличие устаревших технологий обработки данных (известно, что иногда перевести ПО на новые технологические рельсы сложнее, чем написать его заново).
Отсутствие актуальной технической и пользовательской документации.
Несоблюдение принципа «версионности».
Несоответствие маркетинговой информации реальным возможностям ПО.
Финансовая нестабильность разработчика.
С точки зрения стоимости, отечественные решения выглядят привлекательно, однако, как показывает опыт, большинству из них (несмотря на громкие рекламные заявления) под силу автоматизировать лишь только некоторые базовые учетные функции, например: бухгалтерию, кассу, склад и расчёты с контрагентами.
С точки зрения технологического совершенства и полноты функциональной структуры, отечественные ПО значительно (а иногда безнадежно) отстают от западных собратьев, поэтому чаще всего являются применимыми на крупных предприятиях только в качестве заведомо временного решения.
При выборе ПО нужно всегда руководствоваться исходной постановкой задачи. Не стоит пытаться отвечать на возникающие вопросы самому, исходя из прочитанных маркетинговых брошюр. На конкретные вопросы, касающиеся применимости ПО в каждом случае должны отвечать специалисты поставщика, подтверждая каждый свой ответ соответствующей демонстрацией (показом действующей системы у других клиентов, настройкой контрольного примера и т.д.). Особое внимание следует уделять предлагаемой поставщиком политике ценообразования на ПО. Обычно стоимость формируется исходя из количества приобретаемых лицензий на рабочие места по каждому из условных функциональных модулей. Иногда отдельно учитываются серверные лицензии по каждому дополнительному серверу приложений, включенному в итоговую конфигурацию. Если поставщик решения выступает в качестве внедряющей компании, нужно очень осторожно подходить к оценке предлагаемых комплексных вариантов, когда процентное соотношение стоимости продуктов и услуг может изменяться вариативно. Главное правило можно сформулировать следующим образом: любая схема ценообразования должна быть прозрачна и не должна использовать качественных факторов в качестве параметров расчета стоимости.
В заключение следует сказать, что выбор поставщика ПО целесообразно производить в режиме коммерческого тендера, что позволяет максимально объективно анализировать предложения и вести предметный диалог с потенциальными поставщиками.
Принципы выбора прикладного программного обеспечения
После того, как решение о реорганизации бизнес-процессов на предприятии принято, немаловажным этапом является выбор прикладного программного обеспечения, которое будет призвано обслуживать и автоматизировать бизнес на предприятии. Многие компании используют следующий, в принципе вполне возможный вариант - они утверждают: "Мы имеем в штате программиста и он может запрограммировать все от самого начала, до самого конца на базовом языке C++ или Delphi". Конечно, такой подход имеет право на существование, поскольку найти сейчас дешевого программиста еще не составляет труда, но по мнению специалистов, он представляется бесперспективным, хотя бы по двум причинам:
Во-первых, на "пристойное" стандартное программное обеспечение, существующее на рынке, затрачены многие человеко-годы, причем не только на написание самих программ, но и на их отладку.
Во-вторых, программист может в любой момент уволиться и унести с собой все "Know-how", и систему в подобных случаях зачастую приходится переписывать практически "с нуля", в то время, как с приличным поставщиком ПО вы связаны определенным договором.
Более того, как показывает практика, основные недочеты "самопальных" систем выясняются порой уже на этапах их эксплуатации и ведут к разрушительным последствиям, поскольку исправление ошибок требует больших капитало и трудовложений, а самое печальное, оказывается необходимым останавливать систему на неопределенный срок, что влечет за собой фактическое затормаживание бизнеса в ряде направлений, которые непосредственно контролировались с помощью системы, таких, например, как отгрузки или бухгалтерия.
Одной из подобных проблем, возникших в последнее время является наступление нового тысячелетия, в связи с чем на большом количестве предприятий, на которых установлены автоматизированные системы, не поддерживающие четырехзначное летоисчисление возникла необходимость в корне переписывать систему, или немедленно переходить к новой.
При выборе поставщика прикладного программного обеспечения, немаловажным фактором является его финансовая стабильность, потому как финансово нестабильный поставщик программно-прикладной составляющей ИС гораздо хуже, чем финансово нестабильный клиент. Последний омертвляет лишь оборотные средства, а первый, уйдя с рынка, омертвит капиталовложение, потому как исчезнет возможность модернизировать систему, и , в случае сбоя, ею придется заниматься незнакомым с ней специалистам.
Таким образом, можно сформировать ряд критериев, которыми следует руководствоваться при подборе системы ПО:
Система должна быть именно системой, т.е. изменение в одной ее части (скажем, изменения запасов на складе) должны автоматически изменить показатели в других ее раздела (скажем, в бухгалтерских проводках); это свойство системы принято называть интегрируемостью.
Процедуры в автоматизированных системах должны быть действительно автоматизированы. Дело в том, что случается, что после внедрения системы, количество процедур не уменьшается, просто раньше они выполнялись к примеру на бумаге, а сейчас делается все то же самое, но на компьютере.
Система должна обеспечивать реализацию бизнес-процессов и процедур, которые существуют либо должны сужествовать. (оптимальны для конкретного предприятия)
Система должна давать руководителю возможность получать оперативную информацию в объеме, достаточном для принятия оперативных решений.
Система должна быть легка в обучении и использовании (дружественна), чтобы рядовой сотрудник мог научиться выполнять свои обязанности при ее помощи за максимально короткое время.
В системе должна быть заложена возможность без помощи программиста редактировать все необходимые отчеты и документы, менять их форму и создавать собственные форматы.
В системе должны быть заложены процедуры контроля, сводящие ошибки к минимуму.
Система должна давать возможность отследить, кто и когда внес изменения в том или ином файле и какая запись была до этих изменений.
В системах среднего уровня и выше, должны присутствовать надежные программы защиты данных и функции распределения прав доступа.
Системы ПО на российском рынке бывают трех уровней. На первом уровне располагаются простые системы для малого и сверхмалого бизнеса, по цене от 50 до 5000 долларов. В этом сегменте доминируют российские продукты. Их очень много, в основном это программы, предназначенные для простых бухгалтерских функций. Они имеют ограничения по количеству операций, по возможности наращивания дополнительных мощностей, по защищенности данных и другим параметрам, но зато просты в использовании и дешевы.
Второй уровень cоставляют системы по цене 10-80 тыс. долларов и с сопоставимыми затратами на внедрение. Большинство из них - действительно интегрированные системы, поскольку дают возможность весть одновременно и управленческий и финансовый учет. Они не так похожи друг на друга, как системы первого уровня.
Например, в одной из них может присутствовать модуль, разработанный специально для металлургического завода, в другой - нет, но зато могут присутствовать другие важные частности. И поэтому здесь уже не столь важен сам продукт, как то, как он внедряется, и, следовательно, на предприятии должны присутствовать квалифицированные специалисты, хорошо знающие как и бизнес компании, так и специфику ПО. В этом сегменте больше продуктов западных, нежели отечественных. Выбирая западный продукт, первым делом стоит обращать внимание на то, как он привязан к российским реалиям: к законодательству, инфляции и т.п. Здесь стоит заметить, что европейские системы лучше отвечают этим требованиям, нежели американские, так как они были изначально замешены на присущем всему в Европе многообразию, в том числе и в стандартах учета, и поэтому более гибки.