1 задание. Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое
 Скачать 8 Mb.
|
|
Градация и продвижение сотрудников Определяет процесс роста и развития ИТ персонала в компании. Правильно выстроенная система позволяет поддерживать высокий уровень лояльности сотрудников, снизить текучесть кадров, поддерживать высокий уровень мотивации, персональные и технические навыки сотрудников. Градация уровней позволяет использовать механизмов при формировании зарплаты сотрудникам. ИТ Специалист, проработавший в данной компании, более важен компании чем ИТ специалист с теми же навыками, но только прибывший. Это связано с тем, что, хотя технические навыки у каждого равные, но первый знаком с правилами работы в компании, организацией, методами, используемыми в ИТ и т п. что в конечном плане, влияет на эффективность работы. в силу влияния персональных качеств, тот или иной работник одной позиции может иметь разную ценность для компании. Основные составляющие при формировании системы градации могут служить: •Наличие высшего образования •Наличие опыта работы в ИТ •Уровень знаний по продуктам и решениям (набор или повышение, определяет тесты или аттестация) •Наличие опыта и срок работы в ИТ в данной организации (повышение) •Персональные качества •Уровень знаний процедур и процедур (повышение, определяется при аттестации) •Наличие сертификатов и их уровень •Количество часов пройденных курсов •Наличие благодарностей со стороны руководства (повышение) Тестирование и аттестация сотрудников Процесс оценки персональных и технических навыков сотрудников ИТ департамента как при наборе (тестирование), так и при повышении (аттестация). Правильно выстроенная система позволяет поддерживать высокий уровень качества предоставления ИТ сервисов. Ключевые аспекты включают в себя, но не ограничиваются ниже перечисленными: •Наличие тестов при проведении набора в ИТ для оценки технических навыков. •Наличие тестов при проведении набора в ИТ для оценки персональных навыков. •Наличие процедуры проведения отбора сотрудников. •Наличие тестов для проведения аттестации ИТ сотрудников на оценку технических навыков. •Наличие тестов для проведения аттестации ИТ сотрудников на оценку знания политик и процедур. Общий вид процесса отбора ИТ персонала может выглядеть как: •Первый этап – отдел кадров формирует опросник (порядка 20 вопросов из базы вопросов, предоставленных департаментом ИТ). Этому предшествует сбор резюме и заявок в течении двух трех недель. Кроме этого в состав теста добавлены общие вопросы (порядка 10 вопросов математика, логика психология и т п). Сотрудник отдела кадров проводит тестирование с соискателями. Присутствие представителя ИТ департамента необязательно. Определяется пороговое значение для прохождения (например, 60%). На тесты выделено порядка 30 минут. •Второй этап – отдел кадров и представитель ИТ департамента проводят интервью с соискателями прошедших тестирование (через одну неделю после тестов). На данном этапе имеется резюме и результаты теста соискателя. Представитель ИТ департамента проводит интервью на основе опросника для оценки глубины технических знаний и отсутствие подлога в результатах теста. На каждого соискателя выделяется порядка 30 минут. По результатам интервью формируется список «рекомендуемых» кандидатов (порядка трех человек по рейтингу). •Третий этап – встреча с руководителем ИТ департамента и руководителем отдела кадров (через неделю после интервью). Этому предшествует работа департамента безопасности и отдела кадров, по проверку потенциальных кандидатов. На финальном этапе делается предложение кандидату или отказ, определяют, когда кандидат может начать работать. Отдел кадров ожидает по необходимости ответ соискателя (но не более недели). В случае положительного решения, отдел кадров сообщает руководителю ИТ департамента, когда кандидат приступит к работе и закрывает вакансию. Для обеспечения прозрачности и контроля процесса набора сотрудников желается производить регистрацию в течении всего процесса. Также желательно иметь базу кандидатов (прошедших, не прошедших, поданные заявки и резюме). Для оптимизации процесса отбора персонала, желательно определить период, в течении которого кандидат, не прошедший тесты или интервью, может повторно падать на вакансию в организации (как правило от шести месяцев до года). При наборе сотрудников, можно определить позиции, на которые можно производить внешний набор, а для каких желательно использовать внутренние ресурсы. Исключение может составлять случае, когда формируется новый департамент, отдел или подразделение. Как пример можно использовать следующую матрицу Для качественной и количественной оценки сотрудника можно ввести систему оценки, которая помогает организации определить достижение стратегических и тактических целей. Использование ключевых показателей эффективности даёт организации возможность оценить своё состояние и помочь в оценке реализации стратегии. KPI – это инструмент измерения поставленных целей. Если показатель, который вы придумали, не связан с целью, то есть не образуется исходя из её содержания, тогда нельзя использовать данный термин. Преимущества методики – наличие прозрачной системы оценки работы предприятия. Она состоит из показателей и их целевых значений, установленных для каждого сотрудника, списка мероприятий для достижения планового уровня KPI с указанием сроков их выполнения, расшифровки методики расчета по показателям, перечня лиц, которые будут проводить оценку. Такая система позволяет руководству отслеживать в динамике эффективность деятельности каждого подразделения и сотрудника, прогнозировать результаты работы компании за год. Возможность корректировки действий сотрудников в течение года в случае, если результаты их работы не дотягивают до запланированных уровней. Объективность оценки работы сотрудников. Конечно, в случае оценки деятельности работников вспомогательных подразделений, или представителей творческих профессий (дизайнеры и т п) не всегда удается установить количественные показатели. В таком случае применимы качественные. Для эффективной работы методики необходимо создание системы обратной связи, позволяющей специалисту оперативно получать оценку своей деятельности на основе объективных критериев, а не общего впечатления, сложившегося у начальника. Система премирования на основе KPI способствует мотивации персонала к повышению производительности и достижению стратегических целей компании, а также позволяет обосновать размер премии. Плановый уровень бонуса определяется, как правило, в виде процента от оклада работника. Конкретный процент зависит от уровня должности и профиля деятельности сотрудника. Для успешного внедрения KPI следует объяснить сотрудникам предназначение системы, механизм ее работы, преимущества для организации и персонала. Кроме того, нередко нужны специальные тренинги по управлению эффективностью для отдела кадров и руководителей всех уровней. Все это требует не только определенных денежных вложений, но и грамотного исполнения. Лучше не заниматься системой KPI вообще, нежели внедрить неудачно и тем самым дискредитировать ее в глазах сотрудников, которые при следующих попытках наладить работу системы будут относиться к технологии с недоверием. Следует обратить внимание, что затраты на внедрение технологии окупаются в первую очередь на средних и крупных предприятиях, где необходимо обеспечить прозрачность системы управления. В случае небольших компаний, где начальник может контролировать деятельность сотрудников без дополнительного сложного инструментария, затраты на внедрение могут себя не оправдать либо вообще, либо по крайней мере в первые годы работы системы. Рекомендации по эффективному управлению персоналом Можно привести еще много рекомендаций и критериев при отборе сотрудников, но важно помнить несколько «законов жизни»: •Выбор сотрудника – это всегда в какой-то степени лотерея. Надо быть немного везунчиком •Математика и подсчет «попугаев» (галочек в чек листе) не всегда может помочь. Одно гнилое яблоко в вазе со свежими яблоками не станет свежим со временем, а вот то, что все остальные яблоки в вазе также сгниют – факт. •Нанимая молодого руководителя с прекрасными знаниями, но без достаточного опыта, вы оплачиваете не только его знания, но и те ошибки, которые он совершит. •Организация несет больше всего убытков в двух случаях – если сотрудник вор, или если сотрудник дурак. •Не убивайте мотивацию сотрудников. Поощрение новаторских идей, и доведение их до сведения начальства, и настройка механизма обратной связи. Без обратной связи поток творческих идей иссякнет, поскольку новаторы будут считать, что их идеям не уделено должного внимания или они не воспринимаются серьезно. Современная методика DevOps На сегодняшний день, помимо представленных выше классических методов организации деятельности ИТ имеется также и альтернативные решения. Один из вариантов представляет из себя методология DevOps (Development & Operations). Методология находится на стыке разработки и операционного управления. Сама по себе методология DevOps – это не просто набор техник, это философия современного управления ИТ деятельностью. Ее появление связано с изменениями в технологиях за последнее время. По большей части это связано с тем, что организации переходят от классических приложений к быстрой разработке, тестированию, введению в эксплуатацию и сопровождению решений. Это требует быстрой реакции и тесного взаимодействия ИТ подразделений между собой. Переход к DevOps призван уменьшить число конфликтов, возникающих, когда разработчики ориентированы на удовлетворение требований бизнеса, добавление новых функций, удобства использования и т п, а ИТ специалисты традиционно сосредоточены на надежности, безопасности и доступности функционирования ИТ систем. Таким образом, разработчиков нужно учить операционной деятельности, а эксплуатационников – более быстрому и эффективному удовлетворению потребностей бизнеса. Понимание и согласованность действий разработчиков и ИТ специалистов по сопровождению будет способствовать уровню удовлетворенности клиентов. Основополагающая техническая концепция DevOps: по мере автоматизации процессов взаимодействия с инфраструктурой в ходе построения, тестирования, развертывания и мониторинга ИТ организации могут устранить многие операционные дефекты и улучшить разработку и сопровождение решений. На практике, основные вопросы заключаются в том, как и какие инструменты следует использовать по каждой отдельной области DevOps. На мой взгляд, можно провести аналогию, по которой DevOps можно рассматривать как гибкой «Agile» методикой организации ИТ деятельности. Как и в управлении проектами, данная методика имеет свои плюсы и минусы, и ей еще предстоит доказать свою эффективность в течении времени. Перечень и формат руководящих ИТ документов Руководящие документы по управлению ИТ, для удобства, различаются по следующим категориям: ИТ устав и политики – высокоуровневые документы, определяющие общие положения, методы достижения целей и т п. Определяют высокоуровневые значения (например, … длинна пароля должна быть регламентирована …). ИТ Стандарт – документы промежуточного уровня, определяющие метрики для методов, определённых в политиках (например, … длинна пароля восемь символов…). ИТ Процедуры и планы – документы промежуточного уровня, определяющие пошаговый регламент работ для применения политик с использованием метрик стандартов, инструменты, исполнителей, инструкций и т п. ИТ Инструкции и акты – низкоуровневые документы, определяющие инструкции для сотрудников внутри ИТ департамента, конечных пользователей, факты выполнения тех или иных действий и т п. Диаграмма: Уровни управления, задачи и детализации Для удобства организации работы ИТ и снижения административной нагрузки можно принять за правило (если это не противоречит правилам компании), что, все высокоуровневые и промежуточные документы необходимо подтверждать на ИТ комитете, а низкоуровневые документы могут быть разработаны и утверждены директором ИТ департамента. Структура устава ИТ департамента может содержать следующие пункты: Общие положения Цели документа Принятые сокращения и определения Сфера действия документа Организации работы с документом (разработка, внедрение, утверждение и т п) Цели ИТ департамента Задачи ИТ департамента Функции ИТ департамента Структура ИТ департамента Роли и ответственности Порядок взаимодействия Порядок разрешения конфликтов Показатели эффективности и критерии оценки деятельности Контроль документа Контроль версии документа Базовый формат политик ИТ департамента может содержать следующие пункты: Общие положения Цели документа Принятые сокращения и определения Сфера действия документа Порядок организации документа (разработка, внедрение, утверждение и т п) Связанные документы и политики (процессы) Влияние при отсутствии документированной политики (процесса) Цели политики (процесса) Задачи политики (процесса) Процессы и процедуры Под-процесс 1 (процедура 1) Под-процесс 2 (процедура 2) Под-процесс N (процедура N) Метрики политики (процесса) Роли и ответственности Порядок взаимодействия политики (процесса) Риски при внедрении и сопровождении политики (процесса) Ключевые факторы успеха внедрения и сопровождения политики (процесса) Показатели эффективности и критерии оценки деятельности политики (процесса) Отчетность по политике (процессу) Контроль документа Контроль версии документа Детальная Архитектура ИТ сервиса может содержат следующие пункты: Название Назначение Требования Ограничения Архитектура (физическая и логическая) Инфраструктура Зависимости и окружения Лицензирование Мощности Масштабирование Отказоустойчивость и восстановление Резервирование Архивирование Система обновления Роли и ответственности Оценка рисков Тестирование Внедрение Установка Конфигурирование Сопровождение Стандартные Операционные Процедуры Требования к сотрудникам Стоимость Индикаторы производительности Аудит и контроль логов Мониторинг и метрики сервиса Управление Отчетность Рекомендации Выводы и уроки Дополнения и замечания Документ может быть разбит на две части: архитектура сервиса и руководство по операционной деятельности. Для идентичных действий (например, порядок разработки, внедрение, утверждение, нумерации и т п) можно использовать отдельный документ по данному процессу, и соответственно исключить данную секцию из документа. Для небольших организаций, организаций с вялотекущими ИТ процессами, или не значительным влиянием ИТ на бизнес допускается совмещение политик, процедур и стандартов различных процессов в едином документе. Ведение документации один из важнейших элементов административной работы и управления. Никто не любит писать документы… кроме тех, кто умеет. Используйте готовые шаблоны и отчетные формы. Но перед тем как начинать придумывать или заполнять готовые шаблоны, нужно ответить на три важных вопроса: •Какие документы нужны для вашей организации сейчас? •Насколько детально нужно их прорабатывать? •Стоимость времени, потраченное на создание документа по отношению к ценности документа? Генерировать кучу ненужных документов дорого, долго и глупо. Это выгодно, если проект оценивают по толщине отчетных документов. Но толстые документы никто не читает. Их ставят на самую дальнюю полку и забывают навсегда. Поэтому нужно выбрать только те документы, которые нужны для достижения целей проекта. Для результатов. И прорабатывать их настолько детально, насколько это нужно для достижения целей. Логично. Но как определить эту грань? Так как разработка документации и административные работы требуют дополнительных ресурсов, порядок разработки и глубина проработки ИТ документации может быть различной как для различных организаций, так и отдельных процессов в одной организации. Различают важность документов по следующим типам: По степени важности •Устав, планы, бюджет и т п •Политики •Стандарты •Процедуры •Прочие документы По уровню взаимодействия •Взаимодействие ИТ департамента с внешними организациями •Взаимодействие ИТ департамента с подразделениями внутри организации •Взаимодействие внутри ИТ департамента Можно руководствоваться различными методами внедрения: «Классический» – разрабатывается документация и процессы собственными силами или с привлечением консультантов и экспертной группы. Внедрение поэтапное основных и второстепенных процессов. Достоинства: •Наиболее правильный с точки зрения организации •Проработана цепочка «снизу – вверх» и «сверху-вниз» Недостатки: •Достаточно затратный как в финансовом, так и во временном плане •Не эффективен в условиях ограниченных ресурсов «По требованию» – процессы формируются в ходе внедрения и сопровождения ИТ сервисов. Далее происходит их обкатка, и лишь затем формальное документирование, и принятие. Приоритеты также формируются по необходимости. Так, например, в первую очередь прорабатываются процессы взаимодействия ИТ и внешней организации (поставщиками продуктов, компанией разработчиками и т п). На следующем уровне организуются процессы взаимодействия ИТ департамента с другими подразделениями компании. И в последнюю очередь формализуется организация работ внутри самого ИТ департамента. Достоинства: •Эффективен с точки зрения использования ресурсов •Простота и понятность в организации простых процессов •Целевой, направлен на управление наиболее важными «живыми» процессами в организации, а не формально «важными» с точки зрения управления ИТ сервисами Недостатки: •Является реактивным методом, т. е. работает по факту происходящих действий •Требует дополнительного времени и ресурсов по интеграции процессов между собой Техника «постепенного улучшения», которая представляет из себя следующую последовательность действий: •Сначала берете (или выбирается) минимальный набор документов. •Заполняете на основании здравого смысла. Если что-то кажется лишним, отбрасывайте. •Затем оцениваете, сможете ли вы с помощью этой информации достичь нужных результатов. •Если нет, то включите недостающие разделы или документы. •Заполните их и снова проведите оценку. •И так далее до достижения результатов. Выбор метода зависит от индивидуальных особенностей организации и ее культуры, на мой взгляд использование метода «по требованию» с применением техники «постепенного улучшения» является наиболее удачным. Процедура утверждения руководящих ИТ документов в общем случае может выглядеть так: •Для процессов, владельцем которых является ИТ, утверждение возможно по решению ИТ директора •Разрешение конфликта интересов происходит согласно процедуре в два этапа: инициатор и ИТ директор привлекают департамент Аудита. Если конфликт не разрешен, то запрос направляется на ИТ комитет. •Для процессов, владельцем которых ИТ не является, утверждение возможно только по решению ИТ комитета •Ряд документы требует разработку их в других департаментах. При этом соблюдается алгоритм действий: •ИТ ссылается на документ, разработанный в соответственном функциональном департаменте (документы по кадрам, закупкам и т п). Если документ отсутствует в функциональном департаменте, то ИТ разрабатывает его самостоятельно по вопросам, связанным с ИТ с учетом вербальных требований функционального департамента. Для предоставления качественного ИТ сервиса необходимо разработать и внедрить следующие виды документов: •Устав ИТ департамента (01) •Политики и положения (02) •Стандарты (03) •Процедуры (04) •Планы и бюджеты (05) •Должностные инструкции (06) •Сервисные соглашения SLA & OLA (07) •Инструкции и руководства (08) •Акты и формы (09) •Отчеты (10) •Прочие документы (11) |