Вместо предисловия, выдержка из ITIL Service Strategy:
«Многие компании верят, что приобретя или разработав какой-то инструмент, все их проблемы будут сразу решены. Но очень просто забыть о том, что они всё ещё зависят от процессов, функций и, что особенно важно, людей. И запомните – дурак с инструментом – всё ещё дурак».
Сегодня мои размышления про выбор программного обеспечения.
Мудрость того же ITIL, да и собственное мироощущение, говорит о том, что следует выбирать систему автоматизации под свои нужды, а никак не наоборот. Но упрямый опыт показывает, что зачастую выбор системы автоматизации происходит как раз от готового решения, на которое компании пытаются натянуть свои процессы.
На самом деле, это не всегда зло. Почему? Да хотя бы потому что в типовое ПО уже заложены какие-то процессы и механизмы, и зачастую очень неплохие. Умные люди уже подумали о том, как должны двигаться «нормальные» процессы у большинства заказчиков, и почему бы не воспользоваться уже готовыми решениями.
Но хочется поговорить о том, как же всё-таки должно быть по-правильному. А по-правильному это сначала сбор требований, а потом подбор ПО. Подход от обратного заведомо провален. Уверен, у каждого найдётся пример того как были бездарно похоронены инвестиции в ПО, которым никто не пользуется. Этому есть несколько причин. Во-первых, выбранное ПО не соответствовало требованиям (которых, возможно, не было). А во-вторых, иногда всё зависит от недостаточной управленческой «воли» — какой-то руководитель просто не смог настоять на использовании или не предпринял нужных мер для успешного внедрения. Но если на второй фактор мы (представители IT) не всегда можем повлиять, то с первым работать можно. Для выбора ПО авторы ITIL предлагают использовать следующий подход:
1.Сбор требований. Тут существует масса способов как заставить заказчика поделиться своими знаниями. Рекомендую к прочтению: «Разработка требований к программному обеспечению» Дж. Битти, К.Вигерс.
2. Формирование списка программных продуктов. Когда у нас уже есть требования, мы можем начать поиск программных продуктов, которые соответствуют требованиям.
3. Формируем критерии отбора. Для оценки выбора программного обеспечения предназначен MoSCoW-анализ. Что это сокращение обозначает:
Must have – ключевые параметры, без которых внедряемое ПО не имеет никакой ценности;
Should have – важные параметры, которые хотелось бы иметь, но можно отложить на будущее внедрение или доработку самостоятельно;
Could have – Параметры, которое неплохо было бы иметь, если это не будет стоить дорого и не займёт много времени на внедрение;
Won’t have (but would like in the future) – параметры, которые возможно понадобятся в будущем, но на старте внедрения абсолютно не обязательны.
4. Составление короткого списка. На этом шаге мы фильтруем наше ПО, полученное на шаге 2, через сито критериев, определённых на шаге 3. Наибольшую ценность имеют критерии группы Should.
5. Скоринг. После отсева у нас остаётся несколько вариантов. Критериям отбора, собранным на шаге 3, присваиваем баллы в соответствии с ценностью для автоматизируемой деятельности. Продуктам из короткого списка присваиваем оценки.
6. Ранжирование. Сортируем список ПО по поставленным оценкам по убыванию ценности.
7. Выбираем наиболее соответствующий требованиям вариант.
Удачи во внедрениях!
Добавить комментарий