Трудности - IT World

тема номера >
Help Desk
Трудности
выбора
Наверное, пока используются ИТ-системы, будет звучать вечный спор, что лучше: самописное или покупное
решение. Тема это широкая и порой неоднозначная. Попробуем раскрыть ее применительно к одному
из аспектов ИТ — системам обработки заявок пользователей1. Тем более, что такая задача рано или поздно
встает перед каждым ИТ-отделом. И каждый раз ответственное лицо оказывается перед дилеммой — что
выбрать, как не промахнуться, не впасть в соблазн? В итоге принимается решение, и… жизнь показывает,
насколько удачным был выбор.
Искушение самописной
системой
С
амый сильный «лобовой»
аргумент в пользу самописной системы — дешевизна.
Фактические затраты —
труд разработчиков. Если
система несложная, без «наворотов»,
то минимальные трудозатраты составят
около двух-трех месяцев работы одного
программиста. И это с постановкой за-
Александр Башкиров |
ИТ-специалист
46
1
дачи, тестированием и исправлением
ошибок. Система без наворотов — это
жесткие формы заявки, ручное назначение и отсутствие средств контроля за заявкой (кроме статуса). Любое изменение
в логике или доработка формы требуют
пересборки всей системы.
Второй аргумент в пользу такого
рода решения: понимание внутренней
архитектуры, и, как следствие, высокая
адаптивность. Проще говоря, с системой
Они же системы поддержки пользователей, они же системы Help Desk/Service Desk. Прим. автора
IT-MANAGER І декабрь І 12.2011
Help Desk <
не надо разбираться: и так все понятно.
Кроме того, система всегда будет такой,
какой надо. Но! Это работает до тех пор,
пока в компании трудится группа разработчиков. С их сменой это преимущество полностью нивелируется.
Если нужна система более гибкая
(например, с возможностью самостоятельно проектировать формы без изменения кода или с гибкой настройкой
маршрутизации, группирования заявок
и т. д.), то увеличиваются и сроки разработки, и команда разработчиков: такого рода систему можно разработать
где-то за полгода, причем, если повезет,
то с включением в нее механизмов контроля SLA.
Следующий уровень такого рода
систем включает в себя уже совершенно «взрослые» элементы: интеграцию
с внешними системами, поддержку
различных процессов ITIL и т. д. С точки зрения самой системы, развитие
уходит в сторону гибкости и масштабируемости: возникают новые задачи,
и, глядишь, изначально разрабатываемая система контроля заявок превратилась чуть ли не в полноценный CRM,
да еще и кусочек документооборота
под себя подмяла. А потом переросла
саму себя и превратилась в «коробку»,
то есть в продаваемое и тиражируемое
решение. Правда, до такого красивого
финала доживают единицы из тысяч.
В основном судьба самописных систем — остановиться в развитии и со
временем перейти в категорию выводимых из эксплуатации. Справедливости ради надо отметить, что такого рода
система вполне может проработать несколько лет, прежде чем будет принято
решение о бесперспективности ее дальнейшей разработки.
Но если даже говорить о переходе
в «коробочно-тиражируемый» вариант,
то всё все равно выглядит не так гладко, как хотелось бы. Сам процесс вывода на довольно узкий и насыщенный
рынок нового продукта, организация
поддер­жки, оперативное реагирование
на инциденты — это работа, и работа
немалая. Что, в общем, определенные бизнес-риски. И их оправданность
в каждом конкретном случае должна
подтверждаться расчетами и сопровождаться планами.
IT-MANAGER І декабрь І 12.2011
тема номера
В основном судьба самописных
систем — остановиться в развитии
и со временем перейти в категорию
выводимых из эксплуатации
Вообще, по моему мнению, разработка собственной системы управления заявками для собственных нужд — не самая хорошая идея, особенно, если речь
идет о простой системе: гораздо проще,
быстрее и дешевле выбрать, установить
и настроить бесплатную систему (Open
Sorce или аналогичные, распространяемые под свободной лицензией).
Искушение Open Source
На тему Open Source было сломано
уже столько копий, что и писать как-то
неудобно. Тем не менее…
Самый сильный аргумент в пользу открытых продуктов (для краткости будем
под Open Source понимать любые системы, распространяемые под свободными
лицензиями) — бесплатность. Скачал,
установил, настроил и работай.
Однако, как это часто бывает, все не
столь радужно. Первые «грабли», которые поджидают пользователя Open
Source — документация. Ее, как правило, или нет, или она достаточно скудна.
И это вполне можно объяснить: дело
в том, что большинство подобных систем управления заявками не имеют за
плечами спонсоров. То есть существуют
на энтузиазме, на небольшие дотации
от пользователей и… на выручку от поддержки. При таком раскладе логично
оказывается развивать систему, а не
писать документацию. Хотя совсем без
документации тоже нельзя: не будут использовать. В этом случае разработчик
обычно предоставляет нечто типа Quick
Start Guide, а дальше… Дальше разбирайтесь сами (смотрите код и много
думайте — авось, догадаетесь). Или покупайте поддержку. Правда, есть и хорошо документированные системы, но
это скорее исключение, чем правило.
В защиту разработчиков можно сказать,
что не документируют систему они не
по злому умыслу, а в силу приоритетов.
Соответственно, часто документация не
ведется даже для собственных нужд.
Вторые «грабли» — по сути, следствие первых. Архитектура и потенциал
развития системы. Она такая, какой ее
сделали разработчики. А заложили они
в продукт, скорее всего, свое представление о «среднестатистическом» ИТотделе. Соответственно, не стоит ждать
чудес: такое решение будет рассчитано,
в лучшем случае, на 100–200 пользователей, не более. (Под «пользователями»
мы понимаем активных пользователей
системы, а не клиентов ИТ-отдела.)
Тем не менее, такого рода системы,
особенно грамотно подобранные под конкретные требования конкретной организации, — прекрасная площадка для «быстрого старта». Безусловно, в процессе
эксплуатации системы вылезет некото-
47
тема номера >
Help Desk
рое количество проблем, часть из которых решается исключительно «хирургическим» путем… Но никто не говорил,
что будет легко. Фактически, мы имеем
дело с обратной стороной дешевизны —
качеством и понятностью продукта.
Если говорить о возможности автоматизации процессов управления заявками
(и в более широком смысле — процессов ITIL), то такого рода системы обычно
ограничиваются базовым «джентльменским набором»: управление заявками,
проблемами, уровнем сервиса. Реже
можно встретить управление конфигурациями и изменениями. Остальные
процессы в таких системах практически
не встречаются. (То же можно сказать
и про возможности интеграции: чаще
всего системы Open Source интегрируются с LDAP для получения пользователей, а сверх этого в каждой системе
«зашито» что-то свое, уникальное.)
Напоследок замечу, что далеко не
все системы Open Source имеют платную (и вообще какую-либо) поддержку.
Цель большинства из них применительно к управлению заявками — скорее,
система ради системы.
Тем не менее, есть и исключения —
автору известны как минимум две системы Open Source, достаточно прилично
документированные и имеющие платную
(в одном случае даже русскоязычную)
поддержку.
В заключение приведу вывод, сделанный на собственном опыте. Открытые
системы управления заявками использовать можно, особенно для «быстрого
старта» в условиях небольшого (порядка
одной-двух тыс. в неделю) количества
заявок. Далее (через полгода, год, два
года) неизбежно возникают потребности, которые не укладываются в возмож-
ности системы, и она идет на глобальное
обновление — то есть требует замены.
Искушение недорогой
системой
Это, наверное, самое сильное искушение. Хотя бы потому, что «недорогие»
решения бывают разные: от автоматизирующих два-три процесса ITIL до систем,
которые в принципе могут составить
конкуренцию большим брендованным.
Правда, не без пресловутой доработки
«напильником».
С простыми системами все просто:
они, как правило, чуть лучше Open
Source-аналогов и стоят относительно
недорого. При этом их возможности пе-
ются и сложные системы.) Дело хотя бы
в том, что их обычно берут «на вырост»,
а заявленный функционал может иметь
некоторые ограничения (хотя, по факту,
любая ИТ-система имеет ограничения).
Это с одной стороны. С другой — настройка даже существующего функционала силами неспециалистов может вызывать существенные затруднения. Отсюда, как следствие, возникает «эффект
присутствия внедренца». То есть ситуация, в которой обращение к третьим лицам для организации внедрения становится неизбежностью. Это увеличивает
стоимость внедрения (и стоимость владения, естественно), но каждый конкретный случай необходимо рассматривать
От изначального выбора стратегии
зависит то, какую систему
имеет смысл выбирать и стоит ли
вкладываться в потенциал развития
ресекаются с открытыми системами, но,
в отличие от них, такие решения обладают некоторой гарантией и технической
поддержкой. Опять-таки, как правило,
эти системы являются не основными продуктами выпускающих их компаний, что,
в свою очередь, свидетельствует о том,
что поддержка, скорее всего, будет небыстрой, а документация — не такой полной,
как хотелось бы. Но даже в таком варианте у системы на момент покупки и инсталляции будет компания-разработчик,
которая в случае чего окажет поддержку
при внедрении и запуске.
Со сложными системами все несколько запутаннее. (Да, в среде недорогих
систем управления заявками встреча-
персонально. Дело в том, что, например,
сложности, сопутствующие использованию систем Open Source, и временные
затраты на их решение (в денежном выражении) могут быть сопоставлены с затратами на привлечение специалистов
по внедрению. Причем обнаружиться это
может в самый неожиданный момент.
Справедливости ради надо отметить,
что разного рода неприятности могут
возникнуть при эксплуатации любой системы — как бесплатной или дешевой,
так и дорогой.
Искушение брендом
Система, сделанная «под брендом»,
особенно под «мировым», всегда воспри-
ll Таблица. Основные параметры, характеризующие системы управления заявками
Степень сложности
Документирование
Масштабирование
Требования к ап- Поддержка
паратной части
вендора
Минимальная
Слабое или отсутствует
Отсутствует
Небольшие
Самописные
Open Source
Нет
Ограниченная
Стоимость
Условно отсутствует
Недорогие
Минимальная
и средняя
Слабое или
среднее
Слабое
От небольших
до высоких
Ограниченная или
средняя
Невысокая или
средняя
Брендовые
Высокая
Хорошее
Хорошее
Высокие
Полная
Большая
48
IT-MANAGER І декабрь І 12.2011
Help Desk <
нимается как некий прорыв. Потому что
«бренд гарантирует»! Гарантирует то, что
система будет работать, и работать хорошо, а любые нюансы процессов найдут
в ней отражение. Но, как это часто и бывает, есть оборотная сторона медали: как
правило, системы, выпускаемые известными брендами, во-первых, довольно дороги; во-вторых, ресурсоемки; в-третьих,
сложны в освоении. Соответственно, исходя из этого, вырисовывается и область
применения таких систем — большие
и сложные ИТ-отделы, ИТ-компании, центры обслуживания вызовов. Безусловно,
в простом случае (например, управление
заявками) система, разработанная известным вендором, работать будет (более
того, с огромной вероятностью на этот
случай есть готовая конфигурация). Но
это примерно то же, что палить из пушки
по воробьям. Учитывая стоимость лицензий такого рода систем, цена залпа получится неоправданно высокой.
Если же отвлечься от подобных рассуждений и посмотреть на такого рода
системы более пристально, то получим
следующее. «Большую» систему отличают: возможность гибкой настройки и кастомизации (как правило, такого рода
системы включают в себя среду разработки); возможность масштабирования;
хорошее документирование; регулярные
курсы и семинары по системе (организуются, как правило, самим вендором или
его партнерами); поддержка вендора.
При этом поддержка может заключаться
в консультациях, помощи в решении проблем, устранении ошибок и т. д. Ложка
дегтя в этой идиллии обозначена выше:
все перечисленные преимущества так
или иначе оплачиваются потребителем.
И имеют при этом немалую цену.
шинстве своем могут быть отнесены
к системам с минимальным уровнем
сложности, недорогие — к системам
минимального и среднего уровня сложности, брендовые — к высокому уровню. Для наглядности приведем таблицу
с основными параметрами систем, рассмотренных выше.
Вывод из таблицы, в общем-то, очевиден: системы управления заявками
имеет смысл подбирать под конкретные задачи. Например, если требуется автоматизация службы поддержки
уровня среднего центра обработки вызовов (порядка 100–300 операторов),
имеет смысл задуматься о системе,
которая выпущена крупным вендором.
Напротив, если речь идет об автоматизации ИТ-службы из трех-десяти
человек, то следует рассмотреть
Open Sourvce-сис тему, поскольк у
цена, к примеру, серверной лицензии
«большой» (брендовой) системы вполне может быть сопоставима с годовым
бюджетом такого отдела.
тема номера
Следующее, на что стоит обратить
внимание, — планы по развитию. Если
планируемая к внедрению система
в будущем должна обрастать функционалом, то это один вариант. Если
же она должна работать исключительно как «вещь в себе», с тем, чтобы
через несколько лет быть замененной
другой, более «навороченной» системой, это уже другой вариант. Третий
случай, когда система планируется
к поэтапному наращиванию функционала. От изначального выбора стратегии зависит то, какую систему имеет
смысл выбирать и стоит ли вкладываться в потенциал развития.
И, наконец, последний аспект — наличие компетенций. В идеальном случае
компетенции должны быть непосредственно по внедряемой системе. В «не
идеальном» — по технологии, на которой построена система (в этом случае
компетенции по системе наращиваются
в процессе ее внедрения). В общем,
по Сеньке и шапка…
Уровни сложности системы
Чтобы не запутаться во всем, сказанном выше, введем еще один признак
классификации, а именно — условный
уровень сложности системы, который
показывает, сколько процессов ITIL
(а системы управления заявками ориентируются, в основном, на них) может
автоматизировать та или иная система,
и какие возможности развития заложены в ее архитектуру.
Исходя из этого признака, самописные и Open Source-системы в боль-
IT-MANAGER І декабрь І 12.2011
49