Управление заявками на коленке

Получилось так, что на нынешнем месте работы до моего прихода использовались "твердые" заявки на доступ к информационным ресурсам. Минусы такой системы очевидны. Добавим к ним погибающие деревья и эрозию почвы. Плюсы - в случае возникновения инцидента существовала ненулевая вероятность найти заявку с живой подписью провинившегося и жестко его наказать.
Забавно то, что человечек подписывая заявку, обещал все исполнять и утверждал, что ознакомился со всеми стандартами - существующими и не очень. Про несуществующие стандарты - люди расписывались в знании документа "политики информационной безопасности", который не существовал в компании.
Появилось желание ситуацию подправить и за несколько присестов было написано техническое задание (ТЗ) на создание системы управления заявками на доступ к информационным ресурсам. По сути ТЗ было достаточно примитивным, тк оно переносило механизмы движения бумажных заявок в "киберпространство". ТЗ попало к проектировщикам, точнее аналитикам, там было переработано в соответствии с рекомендациями ITIL, соблюдениями SLA и прочей высокоуровневой премудрости. В результате родилось многостраничное ТЗ, со схемами, картинками, табличками, которое нельзя было прочесть меньше чем за час. Стоимость реализации ТЗ и сроки убили первый добрый порыв.  Но ведь мы работаем в крупной серьезной компании! У нас есть что потратить и желание! Был сыгран тендер, он был выигран и компания победитель начала кодить.
Но бумажные заявки раздражали с прежней силой. Тогда мы повстречались с уважаемыми коллегами из техподдержки, которые согласились копировать бумажные заявки в веб-форму, перенабивая каждую строчку (за что им низкий поклон). Затем, с помощью той же техподдержки, на базе уже развернутого шарепоинта, мы сделали табличку, в которой каждая заявка отображалась в виде одной или нескольких строк. Мы договорились, что каждая заявка имеет несколько статусов и каждый человек из цепочки, отработав заявку должен изменить ее статус, для того, чтобы в работу включился следующий. Мы несколько раз встречались с разными исполнителями заявок и их руководителями, чтобы вбить в их светлые головы, что работа без заявок есть зло. В последний момент, когда мы все проверили между собой, я написал формальное письмо о том, что служба безопасности не возражает против оборота заявок без живых подписей и осознает риски возникающие при этом.
Первая живая заявка была введена в систему 18.09.2008, ровно через 4 месяца после трудоустройства и через 2 месяца после появления "неправильной" версии ТЗ.
Так начала жизнь система, работающая по сегодняшний день.
На данный момент, спустя почти 4 года, через нее прошло более 20000 заявок, сделаны некоторые усовершенствования механизмов приема заявок и их сопровождения.
А что же с той замечательной системой, которая разрабатывалась за деньги уважаемой компанией, победителем тендера, спросите Вы. Ее судьба печальна. Акты готовности системы подписаны нужными людьми год спустя. Но новая система требует 8 «кликов» мышкой и отдельного согласования каждой заявки, против 3 нажатий клавиш на клавиатуре в старой системе и возможности согласования заявок группой. А поиск и фильтрация заявок реализовывались в последний момент и как попало.

Оплати телефон SMSкой

Удобная услуга, предоставляемая многими банками, заключается в отправке SMS-ки куда-то, и с счета в банке будет оплачен мобильный телефон. Проблема в том, что SMS-ка стоит денег. Уже смешно? Чтобы узнать, что пора платить за мобильную связь, надо чтобы кончились деньги, а чтобы его оплатить удобным способом, нужно чтобы деньги были. Следовательно, иногда возможны случаи, когда удобной услугой оплаты SMS-кой воспользоваться невозможно....

Тотальная автоматизация и закон сохранения

Иногда (не хочется писать "часто" или "всегда") внедрение того или иного средства автоматизации обосновывается сокращением операционных затрат. Т.е. мы автоматизируем это и то и в итоге получим, что кого-то можно сократить или работа будет менее квалифицированной, что позволит проще относиться к квалификации сотрудников, ибо процесс будет выполняться с такой-то степенью автоматизации и надо будет просто жать кнопки.

Вот почему-то на практике все не так. Почему? Ну, как минимум:
1. Сама автоматизация чего-то стоит. Если система достаточно сложна, то ее внедрение может растянуться на долго, а, может, и навечно - например, потому что автоматизируемый бизнес-процесс за время автоматизации тоже не стоит на месте, что приводит к изменению объемов проекта, что выстреливает в неожиданные трудозатраты и т.п.
2. Чем сложнее система, тем дороже ее поддержка, так как а) требуются более квалифицированные службы эксплуатации и\или б) более дорогие железо и ПО и\или в) если пользователей системы должно стать меньше, то они, как правило, должны стать квалифицированнее (дороже), а если их должно стать больше, то - все понятно.

В общем, скорее всего, автоматизация не приводит к сокращению операционных затрат, ни о каком ROI, как правило, не может быть и речи. Все это происки хитрых маркетологов. Мир банально прост: новая система, новые затраты - в целом. В частных случаях да, возможно, снижение затрат, но в глобальном - всегда, как минимум, сохранение, а обычно - увеличение.

Я бы это сравнил с законом сохранения, когда трудемкости кочуют от бизнес-пользователей к админам, от админов к вендорской поддержке, от вендорской поддержки к вендору, от вендора - к админам и т.п.

Если вспомнить второй закон термодинамики , то операционные затраты в условиях автоматизации вообще не могут уменьшаться!

Принцип Сохранения работает буквально везде.

Например, предполагается, что можно зааутсорсить услуги ИТ (или информационной безопасности) и это позволит Заказчику не держать у себя в штате дорогостоящих специалистов. Ох, не уверен. Давайте вспомним что можно аутсорсить.... Чтобы точно поставить задачу аутсорсеру, предусмотреть все возможные ситуации/риски в SLA, принять работы, проконтролировать/проверить качество этих работ нужен сотрудник квалификации не ниже аутсорсера, а лучше - выше, чтобы он мог успешно снимать лапшу с ушей, навешанную ему ловкими менеджерами успешного аутсорсера (чем аутсорсер успешнее, тем, очевидно, более ловкие менеджеры там работают, а хочется работать с успешными.... => надо крепиться и готовиться :-)). Трудоемкость всех этих работ по возне с SLA, контроле/аудите его исполнения - огромна и требует высокой квалификации. Да, можно будет передать аутсорсеру рутинные, хорошо детерминированные, работы, выполняемые дешевыми специалистами, но, надо будет принять на работу дорогих экспертов. Иначе - все просто рассыпется и интересы Заказчика не будут соблюдены в полном объеме. Управление и контроль - тоже стоят, и немало, - см. п. 7.

Возьмем Россию. Кто-нибудь думает дальше, чем на 3 года? Кто же догадается что от нас останется в следующем году? Понятно.

Что же делать? (пишу в общем виде, поэтому степень абстракции может немного размазать смысл, но, думаю, понятно о чем речь)
1. Не перестраивайте то, что покрывает текущую потребность.
2. Что-то меняйте/внедряйте/автоматизируйте только когда на то есть объективная необходимость.
3. Не внедряйте функционал "впрок", все может поменяться. Развитие ситуации: не стреляйте из пушки по воробьям.
3.5 (следствие) Не гоняйтесь за совершенством! Невозможность его достичь - 3ий закон диалектики. Ориентируйтесь на объективную потребность (повторяюсь).
4. Точно понимайте цель и фиксируйте объемы.
5. Работайте быстро. Не нужны этапные многолетние проекты - максимум год, а вообще - не более 3-6 месяцев, все может поменяться (повторяюсь).
6. Помните, что энтропия - величина неубывающая => упорядочивание стоит.

IDM для замкадышей

Сакральным смыслом данного поста является телепортация знаний из сердца нашей Родины.

Итак, некоторое время над мы рассуждали  об IDM и даже получили ответ .
Сделаем второй шаг и выложим свои идеи бюджетной системы управления учетными записями для небольшой компании, размером в несколько тысяч сотрудников.
Начальные условия следующие:
1. Все пользователи хранятся в Active Directory.
2. Права в системах (всех, любых) даются на основании членства в группах Active Directory.
3. Вновь внедряемые или модернизируемые системы перестраиваются с учетом условий 1 и 2.

Термины и определения:
Базовые права – доступ к внутренней электронной почте и доменная учетная запись.
Шаблон должности – набор прав, характерный для данной должности.
Информационный ресурс - сущность, к которой осуществляется доступ на основании заявки.

Варианты работы с заявками.
1. Прием на работу
При приеме на работу Система, на основании информации из кадровой базы, оформляет и согласует для пользователя автоматически (здесь и далее, действие инициируется сотрудником кадровой службы) заявку на создание почтового ящика для пересылки внутри ИС.
Первый пароль пользователя передается системотехнику, который выходит на настройку компьютера. В свойствах учетной записи должен быть установлен параметр «Обязательная смена пароля при следующем входе в систему».
Система автоматически оформляет заявки в соответствии с шаблоном должности.
2. Увольнение
На основании заявления, кадровая служба обязана в момент получения заявления на увольнение установить параметр пользователя «Подготовка к увольнению». В результате Системой автоматически должны быть оформлены и согласованы заявки на блокировку доступа к следующим информационным ресурсам:
- внешняя электронная почта;
- доступ в Интернет;
- доступ к сменным носителям.
Так же после отъема этих прав, должна быть возможность передать их (автоматически оформить и согласовать заявки) на замещающего сотрудника в момент блокировки старого или позже. Эти заявки так же согласуются автоматически.
Передача прав не может быть осуществлена от одного сотрудника более одного раза.
В начале дня увольнения, в соответствии с заявкой, учетная запись блокируется в 00:01.
3. Увольнение и прием в дочернее предприятие (ДП).
При переводе в ДП в рамках головного предприятия и ДП, действуем аналогично п.2, кроме блокировки в день увольнения.
В начале дня увольнения, на основании информации из кадровой базы, автоматически оформляются и согласуются заявки на блокировку доступа ко всем информационным ресурсам, кроме электронной почты. При этом старым руководителем сотрудника и подразделением безопасности должно быть согласовано сохранение электронного адреса, либо его замена. Эта заявка должна быть подана автоматически не позднее чем за 3 дня до перевода. Если заявка не подана вовремя (заявление поступило в кадровую службу позднее), доступ пользователя блокируется полностью до оформления заявки на перевод с сохранением адреса или оформление в соответствии с п.1. При этом система должна проконтролировать несовпадение электронных адресов.
4. Перевод в другой, независимый отдел в рамках предприятия
При переводе в другое подразделение, в рамках одного предприятия, действуем аналогично п.3
5. Перевод на вышестоящую должность, Перевод на нижестоящую должность, Перевод в рамках отдела
Система автоматически, на основании информации из кадровой базы, оформляет и согласует заявку на блокировку учетной записи в связи с переводом, с указанием вида перевода. У сотрудника отбираются все права, кроме базовых.
Система автоматически оформляет и согласует заявки на предоставление прав в соответствии с шаблоном новой должности.
6. Смена фамилии.
При смене фамилии оформляется заявка (или 2 заявки) которая видна, если поиск осуществляется по старой или новой фамилии. При этом в заявке указывается что на что поменялось.
7. Отпуск, больничный, декретный отпуск, командировка.
При оформлении отпуска, больничного, декретного отпуска и командировки, на основании информации из кадровой базы, автоматически оформляется и согласуется заявка на блокировку учетной записи. По окончании периода блокировки, если это не противоречит информации из кадровой базы, системой автоматически оформляется и согласуется заявка на разблокировку пользователя.
8. Создание удаление инфрмационных ресурсов.
После подачи и согласования заявки, информация о ресурсе добавляется в базу, для оформления заявок на доступ. Бизнес администратор информационного ресурса назначается из числа сотрудников имеющих доступ к ИС. При увольнении сотрудника являющегося бизнес-администратором системы, система должна уведомить руководителя сотрудника, о необходимости назначить нового администратора.


Вот такие мысли. Жду комментариев.

От Мухи до Слона

Мой старший сын в этом году пошел в школу. К моему величайшему сожалению, я не могу ему уделять столько времени, сколько следовало бы прилежному отцу. Но современной школьной программой я стараюсь интересоваться, постоянно сравнивая то, что проходил когда-то я с тем, что проходят нынче.
Изучая прописи, я с ужасом заметил, что теперь детей в школе учат писать с отрывом. Странно, я помню, что меня даже ругали, когда я отрывал руку при написании слова, а теперь почему-то следует писать каждую букву с отрывом от предыдущих. Возможна даже ситуация, когда одна буква пишется в несколько подходов. Что еще более странно, - окончательно написанный текст выглядит как будто написанным без отрыва, т.е. практического смысла в отрыве ровным счетом никакого!
Для меня очевидно, что в письме без отрыва есть тайный смысл - увеличивается скорость письма от руки. Действительно, отрываясь каждый раз после написания буквы тратится время, банально, на отрыв ручки от страницы и на опускание на новое место (а иногда и на то же самое! поскольку окончательно написанное выглядит написанным без отрыва) в странице.
Так что же получается?! Наших детей в школе специально учат писать с отрывом. Зачем? Тут я усматриваю явный заговор. Пишущий с отрывом проигрывает в скорости письма тому, кто пишет без отрыва. Вспомним институт. Необходимо обладать достаточно высокой скоростью письма, чтобы конспектировать лекции. При этом, преподаватель ориентируется на большинство: если большинство успевает конспектировать, темп лекции сохраняется... Представим себе на мгновение, что все резко стали писать с отрывом => медленнее, чем ранее. Это приведет к необходимости снижения скорости лекций, что, в свою очередь приведет к снижению скорости преподавания. Снижение скорости преподавания в современных условиях крайне недопустимо, следует напротив, разрабатывать методы ускорения преподавания, а здесь - напротив, явная мера, направленная на снижение скорости обработки информации, в данном случае - конспектирования.
Уж не знаю, кто так поменял программу, но тяжело допустить, что он был настолько глуп, чтобы не догадаться до столь очевидных последствий. Считаю это заговором против России, тайным злым умыслом, который следует разоблачить и исправить как можно скорее, пока это не дало своих пагубных последствий!