В первые годы жизни организации, когда на штурм рынка идет небольшая группа единомышленников, когда в ведомости на получение зарплаты директор и уборщица расписываются на одной и той же странице, многие вопросы, в том числе и связанные с ...

Искандер Конеев — начальник отдела безопасности компьютерных систем Национального банка Узбекистана. С ним можно связаться по электронной почте: ikoneev@central.nbu.com
Проблемы с установкой и переустановкой программ, настройкой рабочего места рядового пользователя и многие другие решаются в пределах часа. Почти так же просто решаются и вопросы финансирования ИТ-служб. Однако по мере роста организации, когда зарплатные ведомости становятся больше похожими на книги, ситуация, увы, сильно меняется.

Нет смысла пересказывать законы Паркинсона, но в организации, насчитывающей несколько сотен человек, инициация работ (в том числе связанных с ИТ) на основании устного распоряжения или телефонного звонка остается, пожалуй, привилегией только высшего руководства. С ростом самой компании и ее ИТ-подразделения (как его ни называй — управление, департамент или центр ИТ) приходится вводить понятие «организационного (или нормативного) обеспечения». Оно включает в себя всевозможные технические порядки, правила и инструкции по работе в сфере ИТ, предназначенные как для обычных пользователей, так и для администраторов. Эти документы отражают специфику работы конкретной организации с конкретным ИТ-продуктом, а также многое другое.

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

Обрабатывать заявки будет намного легче, если предпринять следующие действия:

  • вести статистический учет видов работ, чтобы разумно перераспределять ресурсы ИТ-персонала в зависимости от трудоемкости работ;
  • планировать будущие работы по материальным, временным, человеческим и прочим параметрам в соответствии с накопленным опытом;

  • избегать дублирования работ по полностью аналогичным или схожим заявкам;

  • получать в рамках заявки всю необходимую информацию для проведения работ, чтобы избегать дополнительного расхода времени на выяснение и уточнение деталей.

Ниже предлагается одна из моделей такой стандартизации в компании, где на ИТ-подразделение возложен широкий спектр задач: установка, переустановка аппаратного и программного обеспечения (включая ремонт оборудования, системную поддержку ПО, консультации по работе стандартных приложений типа Microsoft Office); администрирование сети предприятия, а также крупной многопользовательской прикладной системы; создание ПО для решения конкретных бизнес-задач; решение некоторых других, более мелких вопросов.

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

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

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

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

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


Виды заявок на техподдержку и их параметры

Виды заявокНеобходимые параметры
1. Получение пользователем нового рабочего места (локального компьютера или рабочей станции) или перерегистрация существующего рабочего места с одного пользователя на другого
  • Регистрационный номер компьютера (если компания ведет регистрацию компьютерной техники)
  • Наименование и/или физическое размещение подразделения, в котором будет производиться работа
  • ФИО и должность прежнего пользователя (при перерегистрации) и причина перерегистрации
  • ФИО и должность нового пользователя (или пользователей, если компания допускает много пользователей на одно рабочее место, однако при этом должен быть закреплен один ответственный)
  • Телефон контактного лица, с которым можно согласовать время проведения работ конкретным исполнителем, и другие мелкие вопросы
2. Физическое перемещение оборудования, будь то компьютер, принтер, сканер и т. д. (в том случае, если компания заинтересована, чтобы перемещение техники осуществлялось компетентными специалистами), ремонт аппаратной части или восстановление работоспособности ПО Предыдущие параметры, а также:
  • старое и новое места размещения оборудования
  • для переноса — наиболее удобное время
  • для ремонта — краткое описание неисправности

3. Регистрация пользователя в прикладной системе, а также временное или постоянное изменение статуса пользователя или его функций.

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

  • ФИО, должность, подразделение
  • Функции пользователя в рамках выполнения им своих служебных обязанностей (на основе этой информации администратор сможет точнее определить потребности пользователя в тех или иных функциях системы)
  • Установка тех или иных параметров пользователя в системе (конкретных пунктов меню, уровней доступа или отдельных функций) или изменение этих параметров с указанием срока действия изменений
  • Обоснование установки конкретных параметров, особенно для случаев, когда требуется необычно высокий уровень доступа или возможность использования функций, не характерных для данного подразделения

4. Обеспечение доступа пользователей к различным информационным ресурсам — Internet, корпоративной электронной почте, справочным или архивным системам и пр.

Можно указывать одновременный доступ нескольких пользователей к нескольким информационным ресурсам

  • Включение пользователя в группу с тем или иным приоритетом (если, например, различные пользователи могут иметь разные приоритеты по работе с ресурсом — по времени использования, объему данных и пр.)
  • Указание конкретных наименований архивов или справочных баз данных (если компания применяет разделение доступа к разным массивам информации)
5. Создание или модификация ПО.

Обычно это серьезные виды ИТ-работ, требующие значительного времени и интеллектуальных затрат, поэтому в заявке имеет смысл указывать запрос не на собственно выполнение работ, а на их включение в планы работы ИТ-подразделения

  • Описание сущности задачи. Этот раздел может быть довольно большим, поэтому его имеет смысл вынести в отдельное приложение к заявке (его мы рассмотрим ниже)
  • Планируемые результаты. Их явное указание, с одной стороны, позволяет заказчику определить, что же ему в конце концов нужно, а с другой — дает возможность оценить, какое ПО обеспечивает именно такой или близкий результат
  • Контактное лицо, ответственное за постановку задачи и консультации с точки зрения бизнес-логики
Подробнее рассмотрим различные типы задач, для которых создается или модифицируется ПО (приведенный ниже список, возможно, не полон). При этом, если будет производиться модификация некоторого параметра, необходимо привести его название или указать, где и как можно установить этот параметр
5.1. Создание или модификация отчета.

Задача сводится к сбору множества разрозненных данных в единый удобочитаемый вид

  • ? Периодичность отчета
  • Внешний вид отчета с указанием граф, подграф, их наименование, размеры столбцов, строк и пр.
  • Источники данных (что служит основой для формирования отчета)
  • Правила формирования данной строки данного столбца
  • Пример отчета, каким его видит заказчик
5.2. Создание или модификация расчета.

Задача сводится к построению математических формул или функций и представлению конечного результата

  • Источник данных (что служит основой для расчета)
  • Формулы и правила расчета
  • Форма представления результатов
  • Пример расчета на основе тестовых или специальных данных, демонстрирующих его особенности
5.3. Создание или модификация справочника
  • Наименование полей справочника в том виде, в котором пользователь хочет видеть его содержимое
  • Форматы полей справочника (размеры полей, типы данных и пр.)
  • Источники данных для заполнения справочника
  • Контроль соответствия — указывается, если необходимо следить, чтобы выбранные из справочника данные соответствовали другим параметрам
  • Пример справочника
5.4. Создание или модификация правил логического контроля.

Чаще всего используется совместно с предыдущими пунктами при изменении или добавлении правил формирования отчета, произведения расчета, работы со справочником

  • Источники данных для контроля (что, собственно, контролируется)
  • Правила контроля (соблюдение каких условий необходимо контролировать)
  • Результат контроля (что делать, если условие выполнено)
  • Пример (подлежащее контролю событие и реакция на него)
5.5. Прочие пункты
  • Источник (какие данные используются в автоматизированном процессе)
  • Процесс (что, собственно, делается с данными)
  • Результат (что должно получиться в итоге)
6. Запрос на установку нестандартного ПО*  
7. Заявки, не попадающие в указанную выше классификацию Cтандартные параметры, а также:
  • краткое описание сути работ (в чем они будут заключаться)
  • причина необходимости их выполнения
*Данная заявка используется при необходимости работы с ПО, которое не входит в типовой набор и с которым у специалистов ИТ-подразделения нет опыта работы (например, индивидуальный переводчик с уэлльсского на конкретной рабочей станции), и может быть рассмотрена с двух сторон:
— при наличии свободного времени и возможностей у ИТ-специалистов ее можно рассматривать как задание на проверку, не войдет ли данное ПО в конфликт с существующей системной и прикладной средой;
— при отсутствии таких возможностей — как обязательство пользователя (и руководителя его подразделения) принять на себя всю ответственность за последствия возможно некорректной работы данного ПО.
Все это, естественно, верно для случая, когда компания проводит политику контроля ПО, установленного на компьютерах компании.