Продолжим.
Понятно, что набор диспетчерами заявок во вновь рожденной системе был сизифовым трудом. Поэтому была сделана небольшая веб-форма для набора заявок и пользователям под соусом ускорения обработки заявок, было предложено общаться через эту форму. В результате ее заполнения, генерировалось электронное письмо с обратным адресом диспетчерской, которое шло руководителю, указанному в форме. Руководитель в произвольном формате должен был согласовать данное письмо просто ответив на него. Дальше диспетчер копированием вводил заявку в табличку Sharepoint’а. Этот шаг был необходим по нескольким причинам:
1. Зачастую сотрудник не знал к какому именно ресурсу (точное название) ему необходимо подключиться или формулировал заявку не верно. Поэтому диспетчер корректировал заявку.
2. Иногда одна заявка, например «создание учетной записи», трансформировалась в несколько заявок, формирующих типовой набор прав;
3. Банальная фильтрация «мертвых душ» и грубых ошибок заполнения.
До сих пор в электронных заявках пишется фраза "Предлагаем согласовывать заявки на предоставление доступа к информационным ресурсам в электронном виде..."
Примерно через пол года был сформирован и заморожен актуальный список информационных ресурсов. Пользователям, сначала было рекомендовано, оформить заявку на создание информационного ресурса, с определением его параметров (опять через веб-форму). После пары недель ожидания и напоминаний, заявки на ресурсы не созданные должным образом перестали приниматься. После чего постепенно были решены все вопросы даже по ресурсам, от администрирования которых все отказывались.
Последним «усовершенствованием» оказалась заявка на блокировку учетной записи. Эта заявка должна использоваться при увольнении или переводе сотрудников. Сейчас, когда мы получаем заявку на создание учетной записи, мы просим указывать в цели подключения ФИО сотрудника, вместо которого нанят новый. Это помогло за последний год эффективно проработать механизм блокировки увольняющихся или переводящихся.
Что мы имеем в результате:
1. все заявки за последние 4 года, с возможностью поиска и фильтрации;
2. возможность выдать новому сотруднику все права, которые имел его предшественник;
3. возможность выдать ИТ менеджеру все заявки оформленные сотрудниками его предприятия;
4. актуальный, автоматически поддерживаемый, перечень информационных ресурсов;
5. удовлетворение от проделанной работы.
Что омрачает радость:
1. риск подделки заявок – увы, заявку может заполнить кто угодно и за кого угодно. От этого пока спасает достаточно длинная (не менее 3-х человек) цепочка согласования;
2. риск невозможности использования заявок в случае необходимости обращения в суд;
3. периодические попытки запустить систему, разработанную уважаемой компанией систему.
В данный момент назрела необходимость создания IDM для автоматизации части базовых функций по предоставлению прав. Об этом уже писал. Механизм реализации пока не прозрачен, поэтому откладывается. Заказывать новую систему, не вижу смысла, тк "молоко еще не остыло". Писать столь сложную систему самостоятельно - нет времени и желания. Может космический разум подскажет достойное решение?
Понятно, что набор диспетчерами заявок во вновь рожденной системе был сизифовым трудом. Поэтому была сделана небольшая веб-форма для набора заявок и пользователям под соусом ускорения обработки заявок, было предложено общаться через эту форму. В результате ее заполнения, генерировалось электронное письмо с обратным адресом диспетчерской, которое шло руководителю, указанному в форме. Руководитель в произвольном формате должен был согласовать данное письмо просто ответив на него. Дальше диспетчер копированием вводил заявку в табличку Sharepoint’а. Этот шаг был необходим по нескольким причинам:
1. Зачастую сотрудник не знал к какому именно ресурсу (точное название) ему необходимо подключиться или формулировал заявку не верно. Поэтому диспетчер корректировал заявку.
2. Иногда одна заявка, например «создание учетной записи», трансформировалась в несколько заявок, формирующих типовой набор прав;
3. Банальная фильтрация «мертвых душ» и грубых ошибок заполнения.
До сих пор в электронных заявках пишется фраза "Предлагаем согласовывать заявки на предоставление доступа к информационным ресурсам в электронном виде..."
Примерно через пол года был сформирован и заморожен актуальный список информационных ресурсов. Пользователям, сначала было рекомендовано, оформить заявку на создание информационного ресурса, с определением его параметров (опять через веб-форму). После пары недель ожидания и напоминаний, заявки на ресурсы не созданные должным образом перестали приниматься. После чего постепенно были решены все вопросы даже по ресурсам, от администрирования которых все отказывались.
Последним «усовершенствованием» оказалась заявка на блокировку учетной записи. Эта заявка должна использоваться при увольнении или переводе сотрудников. Сейчас, когда мы получаем заявку на создание учетной записи, мы просим указывать в цели подключения ФИО сотрудника, вместо которого нанят новый. Это помогло за последний год эффективно проработать механизм блокировки увольняющихся или переводящихся.
Что мы имеем в результате:
1. все заявки за последние 4 года, с возможностью поиска и фильтрации;
2. возможность выдать новому сотруднику все права, которые имел его предшественник;
3. возможность выдать ИТ менеджеру все заявки оформленные сотрудниками его предприятия;
4. актуальный, автоматически поддерживаемый, перечень информационных ресурсов;
5. удовлетворение от проделанной работы.
Что омрачает радость:
1. риск подделки заявок – увы, заявку может заполнить кто угодно и за кого угодно. От этого пока спасает достаточно длинная (не менее 3-х человек) цепочка согласования;
2. риск невозможности использования заявок в случае необходимости обращения в суд;
3. периодические попытки запустить систему, разработанную уважаемой компанией систему.
В данный момент назрела необходимость создания IDM для автоматизации части базовых функций по предоставлению прав. Об этом уже писал. Механизм реализации пока не прозрачен, поэтому откладывается. Заказывать новую систему, не вижу смысла, тк "молоко еще не остыло". Писать столь сложную систему самостоятельно - нет времени и желания. Может космический разум подскажет достойное решение?
5 comments:
Прошли практически такой же путь. IDM не внедряем по похожим причинам.
Сейчас прорабатываем возможность изменения владельцев ресурсов и считывания слов типа OK, Approve и т.п. через е-мейл.
+ проработку скриптов и прочей автоматизации для типовых доступов и задач.
Хм.
Если я верно понял, все заявки работают через некоего почтового робота.
Робот пропускает через себя заявки-письма, строя цепочки и считывая ключевые слова.
Тот же робот вносит изменения в ИС в соответствии с заявками.
Идея отличная, но остается несколько НО:
1. зачастую пользователь не знает что ему нужно и без вмешательства человека-оператора заявку сложно
2. иногда в процессе согласования заявка трансформируется или меняется полностью
3. не все системы позволят себя перенастраивать автоматически
4. администраторы ИС могут не пустить скрипты-боты в свою вотчину
А так все отлично! Берем маленькую машинку (виртуалку) с линуксом-почтовиком, прикручиваем к почтарю скрипты и форвардим на эту машинку почту для определенного акааунта. Получаем автоматическую привязку к аккаунтам доменным, прозрачность системы и простоту модификации.
Тема для дипломной работы нескольких студентов.
Игорь,
1. так быть не должно. Есть даже принцип, о котором тебе известно, - Need-to-know :-). Пользователь должен не только знать название ресурса к которому ему нужен доступ, но и как им правильно/безопасно пользоваться. Другое дело, что а) зачастую для названий ресурсов используются почему-то технические названия ролей, типа для SAP-а - ZFI_DFG12_FRTGHJSDF_BBS_KFDFQXS_78T, вместо, понятного конечному пользователю "Управление МВЗ 12", б) каталог ресурсов не популяризован среди пользователей (это несколько нарушает принцип Need-To-Know), но внутри бизнес-функции я считаю, пользователям следут знать какие роли им положены в каких случаях, а вопросы того, что правильные люди запрашивают правильные роли - возложить на Линейного руководителя и Владельца ресурса.
2. Вот с этим вообще непонятно: если у тебя разные согласующие согласуют разную заявку, теряется сам смысл согласования. Заявка сначала должна "трансформироваться" в правильное сосояние (т.е. банально быть правильно заполненной: что пользователь такой есть и работает, что ресурс такой есть, что к нему возможен такой доступ и т.п.), а затм быть согласованной. До тех пор, пока заявка может быть неправильно сформирована, - она может быть откатана сотрудником безопасности. Если автоматизация полностью исключает формирование неправильной заявки (все данные в ней берутся из справочиков с проверкой соответствующих условий), финальное согласование безопасника не нужно вообще, правильность соблюдения процесса гарантируется автоматизацией.
3. согласен.
4. с этим надо работать. Так как это - лишние трудозатраты ИТ, которые можно автоматизировать скриптом, обосновывается экономически. Такого в итоге быть не должно.
Сергей,
Как сказал мне один производственник, при проверке режима КТ: "я зарабатываю деньги, на которые ты потом создаешь мне проблемы". Пользователям не до наших правил, не естественных кстати говоря. А коли правило высосано из пальца то принять его трудно. Поэтому люди делают заявки как придется или получится и фильтр на входе обязателен. Перекладывание ответственности на руководителей - абсолютно бесполезная работа. А вот владельцы ресурса (которые стоят третьими в существующей цепочке согласования) заявку и меняют. Руководитель сотрудника и ИТ-администратор оказываются за бортом измененной заявки, но это слабина, которая пока ни разу не дала сбоя.
Если бы я был администратором, я бы тоже не пустил, наверное, бота в свою систему. Когда бот ошибется, разгребать то мне :). Боты должны встраиваться в систему на этапе проектирования, тогда у них есть шансы.
Про "я зарабатываю деньги...". Вот мне тоже, возможно, доставляет кранее неудобство соблюдение законов РФ, а в случае обращения ко мне милиции, ФСБ, и прочих гарантов безопасности, так и хочется сказать: "я зарабатываю деньги...", а вы мне мешаете это делать своими правилами. Неужели это не очевидно?! Что все правила - и конституция, и ФЗ, и Библия - все это придумано как компромисс между нащими свободами возможность долго и счастливо жить вместе. Логично, если мы не будем напрягаться, работать над собой и убивать каждого, кто отдавил нам ногу или нахамил в метро, мы рано или поздно самоуничтожимся. Так и здесь, все эти правила безопасности я придумал совсем не потому что я хочу мешать работать или мне необходимо обосновать свое существование. Все эти правила безопасности появились как контрмеры на определенные риски безопасности которые хочется минимизировать или как-то иначе управлять. Контроль доступа, в которой пользователь должен указать что он хочет один из таких контролей. Вообще, прежде чем начать работать с системой, пользователю по-хорошему необходимо рассказать как в ней работать, провести инструктаж. Знание того, какие права ему нужны для работы в системе, для выполнения своих производственных обязанностей - элементарное подтверждение уменя работать в системе, знания своей инструкции пользователя систмы.
Но тут еще и другой риск - размывание ответственности. О какой ответственности согласующих можно говорить, когда предмет их согласования изменяется по ходу согласования? Они согласуют что?
Не надо путать то, что пользователь не должен разбираться с технических названия ролей (с этим согласен) и то, что одн должен знать к чему ему нужен доступ. Называйте роли пользователей бизнес-языком и все встанет на свои места.
Лезть в ИТшную вотчину.... А кто об этом говорит? Каждый работает в меру своих возможностей - не умеешь работать головой, работай ногами/руками. Твое дело предложить, а это уже их проблема: нанять 100 студентов по рублю или вообще за практику или нанять одного грамотного, кто все автоматизирует. Тут экономика. На мой взгляд, разумная автоматизация выгодна. Вот только с ее "разумностью" следует разобраться...
Post a Comment