Получилось так, что на нынешнем месте работы до моего прихода использовались "твердые" заявки на доступ к информационным ресурсам. Минусы такой системы очевидны. Добавим к ним погибающие деревья и эрозию почвы. Плюсы - в случае возникновения инцидента существовала ненулевая вероятность найти заявку с живой подписью провинившегося и жестко его наказать.
Забавно то, что человечек подписывая заявку, обещал все исполнять и утверждал, что ознакомился со всеми стандартами - существующими и не очень. Про несуществующие стандарты - люди расписывались в знании документа "политики информационной безопасности", который не существовал в компании.
Появилось желание ситуацию подправить и за несколько присестов было написано техническое задание (ТЗ) на создание системы управления заявками на доступ к информационным ресурсам. По сути ТЗ было достаточно примитивным, тк оно переносило механизмы движения бумажных заявок в "киберпространство". ТЗ попало к проектировщикам, точнее аналитикам, там было переработано в соответствии с рекомендациями ITIL, соблюдениями SLA и прочей высокоуровневой премудрости. В результате родилось многостраничное ТЗ, со схемами, картинками, табличками, которое нельзя было прочесть меньше чем за час. Стоимость реализации ТЗ и сроки убили первый добрый порыв. Но ведь мы работаем в крупной серьезной компании! У нас есть что потратить и желание! Был сыгран тендер, он был выигран и компания победитель начала кодить.
Но бумажные заявки раздражали с прежней силой. Тогда мы повстречались с уважаемыми коллегами из техподдержки, которые согласились копировать бумажные заявки в веб-форму, перенабивая каждую строчку (за что им низкий поклон). Затем, с помощью той же техподдержки, на базе уже развернутого шарепоинта, мы сделали табличку, в которой каждая заявка отображалась в виде одной или нескольких строк. Мы договорились, что каждая заявка имеет несколько статусов и каждый человек из цепочки, отработав заявку должен изменить ее статус, для того, чтобы в работу включился следующий. Мы несколько раз встречались с разными исполнителями заявок и их руководителями, чтобы вбить в их светлые головы, что работа без заявок есть зло. В последний момент, когда мы все проверили между собой, я написал формальное письмо о том, что служба безопасности не возражает против оборота заявок без живых подписей и осознает риски возникающие при этом.
Первая живая заявка была введена в систему 18.09.2008, ровно через 4 месяца после трудоустройства и через 2 месяца после появления "неправильной" версии ТЗ.
Так начала жизнь система, работающая по сегодняшний день.
На данный момент, спустя почти 4 года, через нее прошло более 20000 заявок, сделаны некоторые усовершенствования механизмов приема заявок и их сопровождения.
А что же с той замечательной системой, которая разрабатывалась за деньги уважаемой компанией, победителем тендера, спросите Вы. Ее судьба печальна. Акты готовности системы подписаны нужными людьми год спустя. Но новая система требует 8 «кликов» мышкой и отдельного согласования каждой заявки, против 3 нажатий клавиш на клавиатуре в старой системе и возможности согласования заявок группой. А поиск и фильтрация заявок реализовывались в последний момент и как попало.
Забавно то, что человечек подписывая заявку, обещал все исполнять и утверждал, что ознакомился со всеми стандартами - существующими и не очень. Про несуществующие стандарты - люди расписывались в знании документа "политики информационной безопасности", который не существовал в компании.
Появилось желание ситуацию подправить и за несколько присестов было написано техническое задание (ТЗ) на создание системы управления заявками на доступ к информационным ресурсам. По сути ТЗ было достаточно примитивным, тк оно переносило механизмы движения бумажных заявок в "киберпространство". ТЗ попало к проектировщикам, точнее аналитикам, там было переработано в соответствии с рекомендациями ITIL, соблюдениями SLA и прочей высокоуровневой премудрости. В результате родилось многостраничное ТЗ, со схемами, картинками, табличками, которое нельзя было прочесть меньше чем за час. Стоимость реализации ТЗ и сроки убили первый добрый порыв. Но ведь мы работаем в крупной серьезной компании! У нас есть что потратить и желание! Был сыгран тендер, он был выигран и компания победитель начала кодить.
Но бумажные заявки раздражали с прежней силой. Тогда мы повстречались с уважаемыми коллегами из техподдержки, которые согласились копировать бумажные заявки в веб-форму, перенабивая каждую строчку (за что им низкий поклон). Затем, с помощью той же техподдержки, на базе уже развернутого шарепоинта, мы сделали табличку, в которой каждая заявка отображалась в виде одной или нескольких строк. Мы договорились, что каждая заявка имеет несколько статусов и каждый человек из цепочки, отработав заявку должен изменить ее статус, для того, чтобы в работу включился следующий. Мы несколько раз встречались с разными исполнителями заявок и их руководителями, чтобы вбить в их светлые головы, что работа без заявок есть зло. В последний момент, когда мы все проверили между собой, я написал формальное письмо о том, что служба безопасности не возражает против оборота заявок без живых подписей и осознает риски возникающие при этом.
Первая живая заявка была введена в систему 18.09.2008, ровно через 4 месяца после трудоустройства и через 2 месяца после появления "неправильной" версии ТЗ.
Так начала жизнь система, работающая по сегодняшний день.
На данный момент, спустя почти 4 года, через нее прошло более 20000 заявок, сделаны некоторые усовершенствования механизмов приема заявок и их сопровождения.
А что же с той замечательной системой, которая разрабатывалась за деньги уважаемой компанией, победителем тендера, спросите Вы. Ее судьба печальна. Акты готовности системы подписаны нужными людьми год спустя. Но новая система требует 8 «кликов» мышкой и отдельного согласования каждой заявки, против 3 нажатий клавиш на клавиатуре в старой системе и возможности согласования заявок группой. А поиск и фильтрация заявок реализовывались в последний момент и как попало.
1 comment:
Ситуация подтверждает ряд законов, ранее открытых Опытом:
1. Когда проект длится слишком долго, начинают изменяться условия, что нарушает объем проекта, что нехорошо.
2. Когда нарушается объем проекта, требуется бОльшая гибкость от решения, чтобы покрыть уже изменившиеся потребности.
3. Когда требуется бОльшая гибкость, "коробочность" решения, вопреки ожиданиям, уже является недостатком.
Поэтому меня всегда умиляют консультанты, которые приходят и говорят о том, что они поймут мои потребности в результате N-месячного обследования и на основании выявленных потребностей выберут подходящее решение IDM. Я в это верю с трудом, так как:
1. Пока они будут обследовать, все может поменяться.
2. Они поймут потребности на какой момент времени?
3. "Функционал впрок" - не нужен.
4. Аппртит приходит во время еды, т.е. не факт что потребности мои не будут меняться во времени: сначала хочется просто автоматизировать прохождение заявок, затем хочется, чтобы еще и права в системах назначались сами, потом хочется и автоматической интеграции с HR-системой, потом хочется интеграции со всеми HR-системами, потом....
5. Да и кто же кроме нас самих знает нас лучше :-)
В общем, когда задача до конца не ясна, когда объем не совсем понятен, когда невозможно исключить последующий полет мысли в сторону автоматизации (а это всегда будет, как минимум, нам всем нужны рабочие места :-) - вооружаемся Visual Studio (хотя лично я предпочитаю Perl в vi), что обеспечит нам максимальную гибкость и задел на будущеее.
Post a Comment