Информационные технологии управления / Учебные пособия / ИТУ_Ч2_Зубарев Ю.А., Орлова
.pdfработы по выбору, но и впоследствии участвовать во внедрении и сопровождении программного обеспечения.
Определите, кто будет готовить решение, а кто принимать решение. Выясните, что необходимо руководству для принятия решения. Достаточно ли будет только Ваших рекомендаций или потребуется составление развернутого отчета с детальной сравнительной характеристикой программ.
Выделите сотрудников, которые будут принимать участие в презентациях программных продуктов. Проведите собрание с проектной группой и проинформируйте ее участников о новом проекте, его основных этапах и работах, конечном результате. Такая работа позволит немного сгладить сопротивление сотрудников будущим переменам.
Зафиксируйте эти назначения. Для этого необходимо издать приказ по предприятию, в котором будут отражены как назначения, так и цели. В дальнейшем такой приказ окажет Вам поддержку при проведении работ.
Время
Следующий шаг – это планирование временных рамок проекта. Учитывайте при планировании загрузку сотрудников текущей работой
и календарь руководства.
Четко распланируйте сроки выбора, принятия решения и начала внедренческого проекта.
Главное, постарайтесь не допускать, чтобы проект ―поплыл‖. Добивайтесь соблюдения сроков, для этого используйте метод ключевых точек (вех) по проекту, протоколируйте все совещания и собрания. Обращайте внимание на исполнительскую дисциплину, как рядовых сотрудников, так и РУКОВОДСТВА.
Понятно, что все сотрудники и особенно руководители – люди занятые, но добивайтесь признания важности и значимости этого проекта (здесь Вам немного поможет изданный приказ, о котором мы говорили немного выше). Это создаст соответствующую психологическую атмосферу и настрой, позволит ―приучить‖ людей к порядку. Такой опыт будет полезен и даже очень пригодится Вам на проекте внедрения. Помните, что увеличение сроков проекта – это снижение эффективности вложенных средств.
Осуществление выбора
После того, как все спланировано, Вы готовы приступить к основным работам – выбору ПО.
Исполнителем работ уже будет проектная группа. Хочу заострить Ваше внимание на том, что ограничивающим фактором во время выбора ПО, является также бюджет проекта автоматизации. Отсюда вывод – сопоставляйте требования и возможности.
Разработка целей
Не просто ВАЖНО, а жизненно необходимо в самом начале определиться с целями внедрения. Они, как правило, совпадают с целями
161
бизнеса компании, по крайней мере, должны совпадать. На их основе и под их влиянием будут разрабатываться требования к ПО, определяться этапы внедрения, точнее очередность и логические рамки этапов.
Вы должны для себя ответить на вопрос, с какой целью Вы ввязываетесь в это сложное, но важное дело – внедрение ПО для автоматизации управления? Если Вы не можете сформулировать цель, то, скорее всего, автоматизация будет проводиться ради автоматизации. Некоторые сдвиги в лучшую сторону в работе предприятия будут, но эффект от внедрения будет крайне низким.
Цели могут быть разные. Однако стоит заметить, что чем более четко определена цель, тем проще будет отследить достижение этих целей при выполнении внедренческого проекта. В некоторых случаях для этого потребуется разработать критерии и необходимые условия достижения целей.
Еще один важный момент, касающийся целей – это несогласованность таковых на разных уровнях управленческой иерархии предприятия. Согласитесь, финансовый директор поставит другие цели и будет пытаться решить другие проблемы, нежели главный бухгалтер.
Критерии повышения эффективности
Кроме целей внедрения, Вы также должны определить критерии повышения эффективности работы предприятия, некоторая их часть будет напрямую зависеть от поставленных целей, а другая нет. Т.е. Вы должны определить - за счет чего после проведения автоматизации Ваше предприятие будет работать лучше и за счет чего окупятся затраты на проект внедрения ПО.
Автоматизация управления повышает потенциал предприятия, она позволяет достичь нематериального эффекта, связанного с увеличением стратегического преимущества, как-то, повышение прозрачности учета и инвестиционной привлекательности, снижение барьеров для выхода на международный рынок. И это надо понимать и иметь ввиду при обосновании своего выбора. Часть этих критериев будут качественными, а часть - количественными. Всегда можно оценить, что было до и стало после проекта. Хотя однозначную связь установить трудно.
Для примера приведем некоторую статистику. Хотя она и собрана на примере западных компаний, но с некоторой степенью вероятности может быть использована и на отечественных предприятиях:
Снижение транспортно-заготовительных расходов -60%
Сокращение производственного цикла по заказным изделиям -50%
Снижение задержек с отгрузкой готовой продукции -45%
Уменьшение страховых запасов (уровня неснижаемых остатков на складах) -40%
Снижение производственного брака -35%
Уменьшение затрат на административно-управленческий аппарат -30%
Сокращение производственного цикла по базовым изделиям -30%
162
Уменьшение складских площадей -25%
Увеличение оборачиваемости средств в расчетах - 30%
Увеличение оборачиваемости ТМЗ - 65%
Увеличение количества поставок точно в срок - 80%
Функциональные требования к системе
Следующий этап - разработка функциональных требований к системе. Это один из основных этапов, потому, что именно здесь Вы излагаете свои соображения по поводу того, ЧТО должна делать система, и в некоторых случаях, КАК система должна ЭТО делать.
Вы можете сформулировать свои требования с различным уровнем детализации. Однако необходимо быть уверенным, что выбранный Вами уровень позволит выявить отличия между различными программными продуктами и оценить применимость того или иного ПО в Вашей компании.
Можно остановиться на уровне, описывающем группы функций, выполняемых подразделениями компании, например, управление расчетами с дебиторами, кредиторами, управление продажами и т.п., а можно описать не только требования по наличию тех или иных функций, но и требования по их реализации, например, начисление комиссионных торговым агентам должно производиться только после полной оплаты товара клиентом.
От выбранного Вами уровня детализации будет зависеть и перечень работ по формированию требований и их объемы. Ниже я привожу наиболее общие работы, необходимые для формирования функциональных требований к ПО.
Вначале опишите то, что есть в настоящий момент, как функционируют те или иные отделы, как выполняются различные операции в этих подразделениях. Т.е. проведите обследование деятельности предприятия. Определите проблемы, обобщите их, определите значимость этих проблем и наметьте пути решения. Важно разделить проблемы и задачи, которые могут быть решены путем внедрения системы автоматизации и те, которые требуют других методов, например, изменения учетной политики и т.п. Кроме этого, определите, насколько реализация тех или иных требований к ПО влияет на достижение целей проекта. Например, если главной целью проекта является сокращение сроков разработки и выпуска новой продукции, то реализация в ПО функций интеграции с системой ―Клиент-Банк‖ будет малозначимой.
Следующий этап - планирование изменений. Здесь важно согласовать планы по решению задач и проблем, и планы по развитию компании. На практике мы неоднократно сталкивались с ситуацией, когда планы по развитию бизнеса коренным образом изменяли требования к системе или значительно их расширяли. Например, планы по развитию сети филиалов дополнят требования к функциональности необходимостью поддержки консолидации данных, поддержки корпоративной структуры, наличием функций распределения и пополнения региональных складов и т.п.
163
Полет фантазии и мысли – вещь полезная, однако не увлекайтесь чрезмерно, помните, что у Вас существует бюджет, а добавление новых требований влечет за собой, иногда, ЗНАЧИТЕЛЬНОЕ удорожание всего проекта. Выделите обязательные требования и опциональные, в зависимости от значимости и влияния их реализации на работу компании.
И последнее, при необходимости, опишите модель в формальном виде. Для этого существуют стандарты на описание бизнес-процессов – IDEF0, документооборота – DFD, технологических процессов и потоков работ – IDEF3. Это не так быстро происходит, как может показаться на первый взгляд. При декомпозиции процессов, объем работ по их описанию увеличивается в геометрической прогрессии. Поэтому необходимо определиться с уровнем детализации при описании. В общем случае, уровень детализации должен быть достаточным для того, чтобы модель отвечала на поставленные Вами вопросы. Если Вы уже определили уровень влияния проблем на достижение целей проекта, то более подробно опишите наиболее значимые работы и процессы.
Вы должны быть готовы к тому, что на этапе моделирования столкнетесь с проблемами, которые, условно, можно разбить на следующие группы:
связанные со слабой теоретической подготовкой персонала и недостатком информационных материалов по методологии моделирования;
связанные с получением информации от сотрудников отделов и служб предприятия;
связанные с отображением собранной информации в модели.
Технические требования к ПО
Разработкой требований к операционной системе, серверам и рабочим станциям, авторизации доступа и защите данных, каналам передачи данных, серверам БД и приложений, средствам разработки, а также правил интеграции с существующими программами, могут заниматься сотрудники подразделения ИТ (отдела АСУ, АСУП и т.п.). Хочется обратить еще раз Ваше внимание на соотношение требований и возможностей. Например, при разработке требований к каналам передачи данных необходимо учитывать стоимость передаваемой информации и ее влияние на оперативность принятия решений.
С другой стороны, необходимо помнить, что со стороны ПО также существуют некоторые требования. Например, ограниченное количество СУБД, поддерживаемых системой, использование только определенной аппаратной платформы и сетевой ОС, определенная конфигурация сервера в зависимости от количества пользователей и т.п.
На основании этого Вы можете использовать уровень удовлетворения техническим требованиям, как критерий при сравнении ПО. Особенно это будет полезным, когда вы не планируете значительных вложений в развитие технической базы, т.е. хотите сохранить ее, как есть.
164
Другие требования к ПО
Мы более подробно остановились на формировании функциональных и технических требований к ПО, но не стоит забывать, что существует еще целый ряд требований, не менее важных, например, эргономические требования, наличие демонстрационных и обучающих материалов, требования к локализации и сертификации, и т.п.
Критерии сравнения
Один из самых важных этапов. Здесь есть два момента, на которых хочется остановиться подробнее.
Момент первый – структурированность информации по критериям сравнения. Старайтесь разработать критерии таким образом, чтобы была возможность получить количественную характеристику степени удовлетворения ПО тому или иному критерию. Это позволит избежать субъективизма при оценке и сравнении.
Момент второй – назначение каждому критерию весовых коэффициентов для проведения средневзвешенной оценки. Естественно, можно разработать общий для всех компаний перечень критериев сравнения. И в большинстве случаев и применяется такой список. Самое важное - определить, насколько тот или иной критерий ЗНАЧИМ для ВАШЕГО ПРЕДПРИЯТИЯ, насколько удовлетворение программного обеспечения тому или иному критерию позволит Вам достичь главного – ЦЕЛЕЙ проекта.
Ниже я приведу несколько общих критериев, применяемых при сравнении ПО:
Совокупная стоимость владения;
Функциональная полнота;
Масштабируемость;
Технологичность;
Инвариантность по отношению к бизнесу;
Перспективы развития;
Каждый из критериев состоит из ряда показателей, на основании которых он и рассчитывается. Несколько слов о приведенных примерах.
Масштабируемость. Можно рассматривать функциональную масштабируемость, т.е. возможность при необходимости приобрести или активировать дополнительные модули, которые не требуются на начальных этапах проекта по автоматизации, и масштабируемость по мощности, т.е. способности системы нормально функционировать и оперативно реагировать на действия пользователя при увеличении количества пользователей, количества обрабатываемых документов, росте объема существующих данных.
Технологичность. Это такие показатели как интегрированность (использование всеми модулями одной базы данных, однократный ввод данных и т.п.), интегрируемость (возможность автоматического, полуавтоматического и ручного обмена данными с существующими приложениями), открытость системы (возможность модификации
165
функциональности ПО с помощью встроенных или внешних средств разработки, путем изменения исходных кодов функций и процедур, ядра системы, интерфейсных форм, структуры и модели данных и т.п.)
Инвариантность по отношению к бизнесу. Возможность поддержки программным обеспечением разных видов бизнеса. Например, производства продуктов питания и оказания автотранспортных услуг. Этот критерий особенно важен для корпоративных структур с диверсифицированными видами деятельности.
Перспективы развития. Важно выяснить планы разработчиков в отношении развития и модификации ПО. Были случаи, когда проекты по дальнейшей разработке и поддержке программного обеспечения просто прекращались разработчиками и клиенты оставались один-на-один со своими проблемами по развитию проектов автоматизации.
На остальных критериях я не буду подробно останавливаться, так как совокупная стоимость владения достаточно детально описана в учебниках и литературе по финансам, а расчет функциональной полноты заслуживает большего внимания.
Завершение выбора
Итак, все приготовления закончены, модель работы построена, требования сформированы. Можно приступать к самому интересному и не менее сложному этапу – выбору.
Хоть рынок систем для автоматизации не так и велик, но программ на нем представлено довольно много. Если почитать рекламные материалы разработчиков и поставщиков различных систем, то складывается впечатление, что все программы делают одно и то же, и лишь немного отличаются одна от другой, в основном стоимостью. И у потенциальных покупателей возникает законный вопрос, а зачем покупать и внедрять большую и дорогую систему, если вот есть маленькая и более дешевая, которая делает все то же самое.
Действительно, описать все возможности ПО в рекламном буклете - задача трудная. Кроме того, встречаются разработчики, гордо именующие свое детище ERP-системой, только потому, что это слово модное и им бы хотелось разработать такую систему. Конкуренция на этом рынке довольно высокая и недобросовестная конкуренция, как и везде имеет место быть.
Как же разобраться во всем этом многообразии? Запрашивать демонстрационную версию и детальное описание программ, конечно можно, но только в случае, когда Вам не жаль своего времени и времени своих сотрудников на изучение тысяч страниц технической документации, на инсталляцию демонстрационных версий и попыток разобраться в их логике, а также на ответы назойливым сотрудникам отделов продаж поставщиков. Мы все же предполагаем, что целью этого проекта является выбор ПО для автоматизации управления, а не удовлетворение праздного интереса служащих предприятия к рынку ПО для автоматизации управления (для этого есть другие методы и средства).
166
Определение класса системы
Поэтому, для начала, определите необходимый Вам класс системы. Выбор определенного класса позволит значительно сократить затраты всех видов ресурсов и избежать таких казусов, как участие в конкурсе, например, 1С (и ей подобных) и R/3, что случалось на практике. О классификации программного обеспечения написано много статей и я не буду здесь их цитировать. Естественно, что нельзя определить четкую границу между классами, но выбрать необходимый класс для ориентира, конечно, можно.
Проанализируйте типы задач, решаемых системами одного класса, их основные функциональные возможности, основные стоимостные и временные характеристики проектов по внедрению этих систем. Сопоставьте эти данные с Вашими требованиями и выберите необходимый класс. Существует довольно четкая зависимость между классом ПО, его возможностями и уровнем стоимости. Если в результате анализа Вы получите, что под Ваш бюджет попадает один класс, а под требования – другой, то, явно, необходимо что-то менять. Или умерить аппетит по требованиям или выделять больший бюджет.
Когда эта работа будет завершена, то из тех же отчетов о классификации Вы получите перечень основных, а в случае средних и крупных систем, практически, полный перечень представителей данного класса.
Возможности поставщика
Правильно выбранное программное обеспечение само по себе еще не является залогом успешного проекта. Необходимо еще выбрать поставщика этого ПО. В большинстве случаев поставщиком одного и того же программного обеспечения являются 1-2, реже 3 компании (речь идет о системах для средних и крупных предприятий). Так что выбор не особенно широк. В такой ситуации этот этап приобретает еще большую значимость.
Здесь мы перечислим самые важные моменты, которые необходимо учесть. Они касаются знания поставщиком предметной области вашего бизнеса, модели расчета стоимости проекта, возможностей проведения бизнес-тренингов, возможностей по сопровождению и поддержке ПО, организации и управлению проектом внедрения.
Система управления, точнее ПО ее поддерживающее - довольно сложный инструмент. Эффективность его использования напрямую связана с пониманием пользователем тех алгоритмов, моделей и принципов управления, которые в него заложены. Из нашего опыта следует, что не достаточно показать конечному пользователю ―на какие кнопки жать‖, а желательно, даже необходимо, прочитать ряд тренингов. Например, по методологиям управления MRPII/ERP, стандартам моделирования бизнеспроцессов и т.п. Естественно, что можно заказать такие или подобные тренинги и у сторонней компании, но эффект будет гораздо большим, если их проведет поставщик системы с привязкой к своему ПО.
167
Важно также быть уверенным в знании специалистами поставщика предметной области Вашего бизнеса. Часто компании, выполнивших основную массу своих проектов на небольших торговых предприятиях, стремятся получить проект автоматизации управления на среднем или даже крупном производственном предприятии. Естественно, есть некоторый процент вероятности, что у них получится внедрить более сложную систему на более крупном предприятии, но в большинстве случаев просто переносятся те же методики управления проектами (если они вообще существовали) и организации бизнеса, которые были использованы на небольших проектах. Поэтому постарайтесь встретиться не только с представителями отдела продаж, но и с консультантами, которые потенциально будут работать на Вашем проекте. Постарайтесь узнать, насколько хорошо они знают Вашу предметную область, разбираются в тонкостях и специфике Вашей деятельности, понимают и воспринимают разработанные Вами требования.
Не менее важным фактором, влияющим на успех проекта, является и умение (теоретические знания и опыт) поставщика организовать проект по внедрению ПО и управлять этим проектом. Обычно, существуют стандартные методики внедрения, но не лишним будет поинтересоваться у поставщика:
Наличием в штате менеджеров проектов и перечнем проведенных ими проектов и решенных задач;
Разработанными шаблонами проектной корреспонденции;
Системой организации планирования и отчетности на проекте;
Системой принятия решений при выявлении проблем во время выполнения проекта;
Планируемым распределением ролей между участниками проектной группы;
Согласитесь, что после внедрения ПО, деятельность Вашего предприятия будет существенно зависеть от нормальной работы системы. Поэтому большое значение приобретает качество сопровождения и поддержки поставщиком внедренного ПО. Косвенными показателями уровня качества поддержки могут выступать:
Наличие у поставщика документарно-описанной политики по поддержке клиентов;
Тщательность проработки контракта на сопровождение и техническую поддержку;
Наличие отдельного подразделения, занимающегося техническим сопровождением;
Наличие специальных каналов связи (выделенные телефонные номера, адрес электронной почты, сайт, страницы в Интернет, посвященные поддержке);
Наличие специализированного ПО для автоматизации процесса приема и обработки проблем, возникающих у клиентов.
168
При правильной организации как проекта по внедрению, так и по сопровождению, нет ничего страшного в том, что поставщик не находится в Вашем городе, регионе. Главное, чтобы быстро и качественно решались Ваши проблемы, а для этого поставщику совсем не обязательно находиться ―под боком‖, даже напротив, поскольку стабильная работа системы не требует постоянного присутствия поставщика.
И последнее, на рынке сложилось несколько систем оплаты работ поставщиков. Первая – повременная. Суть ее состоит в том, что после определенного временного промежутка Вам выставляют счет за работу консультантов. Основной недостаток – непонятно, сколько будет стоить весь проект. Вторая модель– бюджетная - приобретает все большую популярность. Ее суть в том, чтобы в самом начале проекта как можно более точно оценить трудозатраты и определить временные и финансовые рамки проекта. Преимущества налицо. Вы всегда знаете, когда и за что должна осуществляться оплата, сколько стоят работы по каждому этапу и во сколько Вам обойдется весь проект.
Еще один момент, который часто наблюдается в реальной жизни – демпинг поставщиков. Обычно его применяют начинающие компании, чтобы выйти и закрепиться на рынке. Будьте уверены, что качество и количество услуг будет соответствующее цене. Вы, наверное, с опаской отнесетесь к предложению купить исправный и не очень подержанный ―600-й Мерседес‖ за 5-7 тыс. долл. Так и здесь. Как говорят англичане – мы не такие богатые, чтобы покупать дешевые вещи.
Запрос на предложение
После завершения работ по всем вышеперечисленным этапам, Вы всѐ знаете о том, какими должны быть система и ее поставщик, но беда в том, что об этом пока не знают потенциальные поставщики.
Существует довольно много схем и правил организации конкурсов и тендеров, и Вы можете ими воспользоваться. Но как быть, если Ваше предприятие не планирует проведение полномасштабного тендера, а всего лишь необходимо отобрать 3-4 поставщика для участия в конкурсе. Рынок услуг по автоматизации управления и консультированию в области информационных технологий - растущий и перспективный, что влечет за собой появление на нем массы фирм, декларирующих выполнение работ по автоматизации. На практике же, качество их услуг довольно низкое.
Чтобы оценить серьезность намерений и профессионализм потенциальных поставщиков, я предлагаю воспользоваться следующей схемой, которая доказала свою жизнеспособность, пройдя проверку на практике.
Во-первых, составьте и разошлите информационное письмо о том, что Ваше предприятие планирует начать проект по автоматизации. В нем кратко опишите условия участия в проекте и запросите краткую информацию о поставщиках.
169
Во-вторых, нет надобности в передаче всем потенциальным поставщикам результатов Вашей работы. Достаточно будет сформировать и направить откликнувшимся на Ваше информационное письмо компаниям некоторый документ, который я бы назвал ―Запрос на предложение‖. В нем кратко опишите свое предприятие, цели проекта, требования к системе и поставщику, критерии сравнения и т.п.
В-третьих, сформулируйте критерии для сравнения предложений, проведите анализ поступивших документов и выберите 3-4-х поставщиков.
Будьте уверены, что Ваше время, потраченное на эту процедуру, не пропадет зря. Как показывает практика, на каждом следующем этапе потенциальных конкурсантов становится все меньше, и остаются только те, кто действительно не просто заинтересован в выполнении Вашего проекта, но и могут выполнить его на должном, качественном уровне.
Сценарий презентации
Правильно разработав требования к презентации и сценарий ее проведения можно достичь как ощутимого эффекта от ее проведения, так и экономии временных, а иногда и финансовых ресурсов компании.
Вот несколько советов, которые помогут Вам получить максимальный эффект от презентации программного продукта. В них нет ничего необычного, но часто об этом просто не думают или забывают.
Создайте для поставщика комфортные условия – сэкономьте свое время и концентрацию внимания слушателей. Хотя докладчики сами должны заботиться о работоспособности аппаратуры, используемой в процессе презентации, и предусмотреть разные неприятные ситуации, но постарайтесь и Вы, чтобы в это время электрики, случайно, не начали ремонт проводки, чтобы удлинитель для подключения компьютера и проектора был достаточно длинным, если помещение достаточно большое, а слушателей много - чтобы присутствовал нормально работающий микрофон и т.п.
Постарайтесь разбить презентацию на несколько частей – пленарную и секционную. Во время первой части могут присутствовать все заинтересованные сотрудники, чтобы познакомиться с идеологией системы, ее основными возможностями и преимуществами. Во время второй части организуйте группы по функциональным направлениям – финансы, логистика, производство и т.п.
Обязательно пригласите на презентацию первых руководителей Вашего предприятия или организуйте небольшую презентацию специально для них.
На презентации, какой бы длительной она не была (всегда есть ограничения по свободному времени сотрудников и эффективному усвоению материала), невозможно полностью показать все возможности ПО, поэтому перешлите поставщику наиболее интересующие Вас темы и вопросы, ответы на которые Вы бы хотели получить на презентации.
Эффектно построенная презентация, красивые слайды и пламенные речи докладчиков производят впечатление. Но очень часто на презентациях
170