20276 Формирование организационной структуры в ИТ-службе предприятия
Содержание:
Введение 3 Глава.1 ИТ-подразделение компании, понятие, значение, цели и задачи 7 1.1. ИТ-подразделение определение 7 1.2.Цели и задачи ИТ-подразделения 16 1.3. Методология формирования оптимальной организационной структуры в ИТ-службе 20 1.3.1. Руководящие принципы управления ИТ-подразделением 30 1.3.2. Технологические принципы 37 Глава 2. Организационно функциональная структура ИТ- службы компании на примере Сбербанка РФ 41 2.1. Описание структуры ИТ- службы компании 41 2.2. Описание пакета нормативно методической документации, регламентирующей деятельность ИТ – службы 45 2.3. Анализ деятельности ИТ – службы 48 Глава 3. Формирование оптимальной организационной структуры в ИТ-службе компании 63 3.1. Различные методы формирования оптимальной структуры ИТ – службы 63 3.2. Сравнение различных вариантов организационной структуры ИТ – службы 77 3.3. Рекомендации по созданию эффективной организационной структуры ИТ – службы 84 Заключение 95 Список использованной литературы 98 Приложения
Введение
Наличие большого объема денег у ведущих отраслей российской экономики (нефтегаз, металлургия, энергетика и др.) в предыдущие годы создавало предпосылки не всегда продуманных решений при формировании ИТ-бюджетов. Впервые за долгие годы появилась возможность открывать одновременно много интересных ИТ-проектов. Это был период больших экспериментов. Руководители ИТ-департаментов спешили удовлетворить свои профессиональные амбиции, стать авторами (инициаторами) грандиозных ИТ-проектов. Такая «мелочь», как техподдержка действующих ИТ-систем, забывалась или передавалась целиком на аутсорсинг. В условиях кризиса и неопределенности для большинства российских предприятий ситуация в области ИТ состоит, как правило, в следующем: с одной стороны, руководство требует оптимизации и сокращения бюджетов; с другой стороны, необходимо обеспечить решение новых задач в соответствии с антикризисными стратегиями собственных компаний. Сегодня, в условиях кризиса, все виды финансовой активности ИТ-департаментов разделились на три уровня: 1) текущая техподдержка действующих ИТ-систем — надо финансировать, поскольку данные системы стали неотъемлемой частью бизнеса; 2) стартовавшие, но незавершенные проекты ИТ-систем — надо финансировать, успешные проекты или реализованные более чем на 70 %; 3) новые проекты ИТ-систем — надо финансировать быстро окупаемые проекты или те, что направлены на создание систем верхнего уровня управления (корпоративный уровень): стратегия, бюджетирование, контроль. Однако в 2009 году руководители ИТ-департаментов и ИТ-компаний впервые столкнулись с проявлением полного скептицизма менеджеров и собственников промышленных компаний по отношению к информационным технологиям. У ряда промышленных компаний в ИТ-бюджете осталась только социальная строка в виде зарплаты сотрудников сокращенного ИТ-департамента. Актуальность нашей работы, не вызывает сомнения, и обосновывается экономической ситуацией в стране. Именно сейчас, а не в эпоху грандиозных проектов, важна методология формирования оптимальной организационной структуры в ИТ-службе современной компании. Почему-то все в один момент забыли о пользе информационных систем для бизнеса, особенно в период кризиса. Ошибкой вдвойне будет не вкладывать деньги в ИТ-системы, очевидно приносящие экономию (пользу) бизнесу, поскольку в предыдущие годы на их создание были затрачены немалые деньги именно для того, чтобы эти системы «заработали» на бизнес в тяжелые времена. Цель моей дипломной работы: создание эффективной организационной структуры в ИТ-службе современной компании. Задачи, которые позволят, достигнуть, поставленную мною цель, следующие: 1. изучение определения ИТ-подразделение компании, понятие, значение, цели и задачи, принципы управления и технологические принципы; 2. рассмотреть организационно функциональную структуру ИТ- службы компании на примере Сбербанка РФ, провести ее анализ; 3. дать рекомендации по созданию эффективной организационной структуры ИТ – службы. Теоретической базой работы служат работы следующих авторов: Ананьин В. И. Формирование архитектуры корпоративной информационной системы путем естественного отбора, Минцберг Г. Структура в кулаке. Создание эффективной организации. Ананьин В. И. Устойчивость управления ИТ-проектами в условиях неопределенности, Ананьин В. И. Границы применения сервиса. ITIL и ИТ-архитектуры и др. авторы. Методика исследования: теоретический обзор литературы, математико - статистические исследования, анализ данных. Объект исследования: методология создания организационно функциональной структуры ИТ-подразделения компании. Предмет исследования: организационно функциональная структура ИТ-подразделения компании. Структура работы состоит из: введения, трех глав, заключения, списка использованной литературы и приложений. введение, где обоснована актуальность работы, цели, задачи работы, объект и предмет исследования; глава первая «ИТ-подразделение компании, понятие, значение, цели и задачи » содержит определение, ИТ-подразделения компании, принципы создания, цели и задачи, которые выполняет данное подразделение, методологию создания; в главе второй работы «Организационно функциональная структура ИТ- службы компании на примере Сбербанка РФ », мы исследуем описание структуры ИТ- службы компании, документационное обеспечение, проводим анализ деятельности службы; в третьей главе «Формирование оптимальной организационной структуры в ИТ-службе компании» предлагаем мероприятия по созданию эффективной организационной структуры ИТ – службы; в заключении работы, мы обосновываем достижение поставленной цели и задач, делаем выводы о проделанном исследовании. Новизна и научная значимость работы: результаты нашего исследования можно использовать в целях создания организационной структуры ИТ – службы, в зависимости от целей и задач решаемых компанией в бизнесе.
Глава.1. ИТ-подразделение компании, понятие, значение, цели и задачи
1.1. ИТ-подразделение определение
ИТ служба (ИТ подразделение) – подразделение предприятия отвечающее за внедрение или сопровождение ПО и технической инфраструктуры и оказывающее ИТ услуги пользователям. Суть деятельности ИТ-департамента состоит в управлении предоставлением информационных услуг (IT Service Management), а результатом ее являются обоснованные по стоимости, надежные, согласованные между собой и имеющие надлежащее качество информационные услуги. Способы организации основного бизнеса и деятельности ИТ-департамента во многом схожи, а некоторые процессы, такие, как управление качеством «конечной продукции», являются сквозными и обязаны быть согласованными на всех уровнях производства. «Информационная услуга» — является результатом деятельности ИТ-департамента, обладает измеряемым качеством и предназначена для удовлетворения потребности пользователей ИТ-услуг в информации. На промышленном предприятии такими пользователями являются сотрудники основного производства, которым для выполнения своих обязанностей необходима информационная поддержка со стороны ИТ-департамента. Теперь перейдем непосредственно к рассмотрению тех процессов которые происходят внутри ИТ подразделения, и которые направлены непосредственно на предоставление и поддержание сервисов. Таких процессов 10 штук: процесс управления инцидентами; процесс управления проблемами; процесс управления конфигурациями; процесс управления изменениями; процесс управления релизами; процесс управления уровнем сервиса; процесс управления мощностями (емкостью); процесс управления доступностью; процесс управления непрерывностью; процесс управления финансами. Мы рассмотрим только пять основных процессов. 1. Начнем с понятия инцидент. Предоставление ИТ сервисов всегда сопряжено со сбоями или, по крайней мере, с затруднениями. Инцидент – это любое событие, не являющееся частью нормального функционирования сервиса, которое привело или может привести к прекращению предоставления сервиса или к снижению его качества. Также можно дать и более простое определение. Инцидент – это любое событие, связанное с инфраструктурой, которое не может быть оставлено без ответной реакции. Т.е. инцидент это не обязательно сбой или ошибка. Основная цель процесса управления инцидентами – это как можно скорее восстановить нормальное (соответствующее SLA) предоставление сервиса. Причем устранение необходимо произвести как можно в более сжатые сроки и, возможно, без выявления корневой причины инцидента. Волне допустимым является так называемое обходное решение (Work-around). Все действия, независимо от того привели они к успеху или нет, должны фиксироваться. Эта информация может быть использована другими процессами для анализа ситуации. Анализ обращений пользователей показывает, что существуют три категории инцидентов: Сбой. Что-то не работает или работает не так, как должно. Запрос на обслуживание. Сбоя и неполадок нет, но обращение зафиксировано. Запрос на обслуживание не содержит информации о неработоспособности предоставляемого сервиса - это вид работ, запрашиваемый у вас, без возникновения ошибки в работе систем. Это обращение может быть связано с оказанием технической поддержки пользователю. Также обращение может быть связано выполнением регламентных работ. Запрос на изменение. Сбоя снова нет, однако пользователи требуют определенных изменений в инфраструктуре. Поступивший запрос требует согласования и вполне может быть отклонен. Под ИТ-инфраструктурой организации понимается вся совокупность имеющихся в ней сервисов и систем, сетей, технических и программных средств, данных, автоматизированных процессов. Выполнение этих запросов связано с существенным изменением в инфраструктуре. Выполнение их может быть проведено только после дополнительного исследования и согласования со всеми заинтересованными сторонами. Все запросы в обязательном порядке классифицируется службой «ServiceDesk». Уже на этом этапе некоторые запросы пользователей могут быть отклонены, как несоответствующие задачам ИТ подразделения. Это позволяет экономить рабочее время ИТ персонала. На должности специалистов ServiceDesk как правило ставятся менее квалифицированные кадры, с меньшим уровнем заработной платы. Фильтрация обращений позволяет снять нагрузку с более квалифицированных сотрудников, которые потенциально могут быть задействованы для разрешения проблем. В организации могут присутствовать несколько уровней поддержки. В случае если вопрос не решается на низшем уровне, он передается на следующий более квалифицированный уровень. Линии тех. поддержки могут выглядеть следующим образом: Нужно стремиться к тому, чтобы решить проблему как можно на более низком уровне. Для этого, в частности, существует корпоративная база знаний, в которой накапливаются возможные решения типовых вопросов. И так, процесс управления инцидентами состоит из следующих операций: выявление и регистрация; классификация и начальная поддержка; поиск решения; применение решения (выполнение определенных действий ИТ специалистами); закрытие; контроль, информирование и отчетность. Закрытием называется формальное (официальное) прекращение работ над инцидентом. Как правило, закрытие состоит в проверке того, что пользователь согласен с тем, что инцидент устранен. Операция «Контроль, информирование и отчетность» следит за ходом устранения инцидента и, при необходимости, генерирует управляющие воздействия. Как правило, это эскалация инцидента на следующий уровень. У процесса «Управление инцидентами» как и у любого другого процесса есть свои параметры (метрики), по которым контролируется качество этого процесса. Метриками в частности являются: среднее время устранения, процент инцидентов устраненных вовремя, процент инцидентов устраненных Service Desk без обращения к более высоким уровням поддержки и т.п. На основе этих показателей делаются соответствующие выводы о совершенствовании методов работы. Выгоды от управления инцидентами: снижение потерь для бизнеса; повышение продуктивности сотрудников; точная картина происходящего; эффективность руководства. 2. Управление проблемами. Целью данного процесса является снижение количества инцидентов. Для её достижения этот процесс ищет причины возникновения инцидентов и инициирует действия по улучшению ситуации. Что же такое проблема? Проблема – это неизвестная корневая причина одного или более инцидентов. После того как решение проблемы найдено, она становиться известной ошибкой (known error). Известная ошибка – это проблема, причина которой выявлена. В целом, процесс управления проблемами состоит из двух параллельных потоков: реактивного (Управление проблемами и управление ошибками) и проактивного, направленного на предотвращение появления подобных ошибок в будущем. В рамках фазы управления проблемами происходит идентификация, классификации и исследование проблем. Проблема сравнивается с существующей базой знаний. Возможно, решение уже было найдено раньше. Как только причина проблемы обнаружена, процесс переходит в стадию управления ошибками. Процесс управления ошибками нацелен на изменение компонентов инфраструктуры таким образом, чтобы устранить известные ошибки и предотвратить повторное появление инцидентов. Не все ошибки необходимо устранять. Все зависит от экономической целесообразности. Иногда дешевле мириться с определенными некритичными ошибками, чем тратить значительные ресурсы на их устранение. Параллельно необходимо выполнять проактивное управление проблемами, а именно проводить анализ тенденций в поведении ИТ инфраструктуры и организовывать превентивные действия. Известные ошибки, требующие изменения инфраструктуры порождают запрос на изменение. Таким образом, мы плавно переходим к одному из следующих процессов – «Управление изменениями». Однако, прежде чем что-то менять, нужно точно знать где что находится и как взаимосвязаны компоненты инфраструктуры. В этом нам поможет процесс «Управление конфигурациями». Выгоды от процесса управления проблемами: снижение потерь для бизнеса за счет уменьшения количества инцидентов; улучшение качества сервисов, и, как следствие, рост доверия со стороны заказчика. 3. Управление конфигурациями. Для успешного выполнения своих обязанностей ИТ персонал должен иметь полную и актуальную информации об ИТ инфраструктуре. Если администратор или работник службы Service Desk точно не знает состав и взаимосвязь компонентов инфраструктуры, он не сможет оперативно и качественно решать возникающие вопросы. Целью процесса управления конфигурациями как раз и является создание и поддержание в актуальном состоянии логической модели инфраструктуры. Процесс состоит из 5 операций: планирование; идентификация; контроль; отчетность; аудит. На этапе планирования процесса управления конфигурациями создается специальная база данных конфигурационных единиц (CMDB Configuration Management DataBase), являющаяся по большому счету логической моделью инфраструктуры. CMDB состоит из конфигурационных единиц (CI) и их взаимосвязей. Конфигурационными единицами являются не только компьютеры и программы, но также документация и сервисы. В ряде случаев пользователи тоже могут быть рассмотрены как конфигурационные единицы. В рамках операции идентификации все CI должны быть обнаружены, поименованы и соответствующим образом промаркированы. После этого их можно заносить в CMDB. Также на этом этапе должны быть построены логические связи между конфигурационными единицами. На практике логические связи обычно более сложные и включают в себя как аппаратные, так и программные компоненты. Любое изменение инфраструктуры предприятия должно находить отражение в CMDB. Непосредственное изменение CMDB возможно только из процесса управления конфигурациями, под управлением операции контроля. Эти простые правила гарантируют актуальное состояние CMDB. Никто не в праве самостоятельно изменять компоненты инфраструктуры и связи между ними, а также неподконтрольно менять логическую модель. Операция «Отчетность» позволяет в любой момент времени получить срез текущего состояния CMDB. Если все организовано правильно, этот срез будет соответствовать реальному положению дел в ИТ инфраструктуре. Выгоды от процесса управления конфигурациями: всегда актуальная информация о состоянии ИТ инфраструктуры; сокращение затрат на ИТ; основа для улучшения качества сервисов; основа для финансовой оценки сервисов. 4. Управление изменениями. Невозможно представить себе инфраструктуру, работающую без изменений на протяжении длительного времени. Потребность в изменениях может возникать по различным причинам, будь то необходимость устранения и предотвращения проблем, потребность повышения качества сервисов или просто необходимость соответствовать изменившимся требованиям бизнеса. Не смотря на то, что каждое изменение планируется с целью оказать позитивное воздействие на инфраструктуру, потенциально из-за неправильного планирования или некорректного внедрения возможно возникновение негативных последствий для ИТ инфраструктуры. Целью процесса Управления изменениями является обработка всех изменений стандартными методами и процедурами, с тем, чтобы минимизировать ущерб для бизнеса, вызванный этими изменениями. Чтобы обеспечить это, процесс состоит из следующих операций: регистрация и фильтрация; оценка; координация внедрения; обзор после внедрения. На первом этапе все запросы на изменения регистрируются, а некорректные, непрактичные и заведомо невыполнимые запросы отфильтровываются. Запросам на изменение выставляется приоритет в соответствии с которыми, эти запросы будут в последствии реализовываться. Запросы на изменение также в обязательном порядке классифицируются по степени воздействия на ИТ инфраструктуру. Запросы с высокой степенью воздействия дополнительно анализируются и одобряются со стороны высшего руководства. В тоже время, вопросы с низкой степенью воздействия (например, перенос принтера с одного рабочего места на другой) могут быть выполнены без дополнительных одобрений. Каждое изменение (особенно серьезное) требует соответствующего планирования и одобрения с финансовой, технической и бизнес стороны (со стороны потребителей сервисов). Серьезные изменения, как правило, должны пройти предварительное тестирование. Однако, эта задача лежит за пределами процесса управления изменениями. Процесс управления изменениями только готовит план, назначает ответственных и контролирует внедрение изменения. В ряде случаев на этапе внедрения выясняется, что изменение не может быть проведено. Для этого должен быть разработан план отмены изменения (Back-out). После проведения изменения нужно оценить его успешность. Это делается на этапе обзора. Определяется, достигнуты ли поставленные цели, довольны ли заказчики, не возникло ли новых проблем. Выгоды от управления изменениями: уменьшение негативного воздействия от изменений; более точная оценка затрат на изменения; полная информация об изменении как до начала, так и после окончания его внедрения; повышение производительности персонала при проведении изменений; устойчивость ИТ инфраструктуры к изменениям. 5. Управление релизами. Когда накапливается значительное количество изменений, можно говорить о том, что ИТ инфраструктура претерпит существенное преобразование и прейдет в некоторое новое глобальное состояние. Релиз – совокупность одобренных изменений. Релизы делятся по масштабу (мелкий/обычный/крупный) и по срочности (экстренный/срочный/не срочный). В рамках релиза определяется единица релиза – часть инфраструктуры которая изменяется целиком. Релиз может быть как полным так и частичным, в зависимости от того все ли компоненты релиза заменяются. Каждому релизу присваивается идентификатор (v.1.0, v.1.0.1, v.2.0 и т.д.). Кроме того, несколько полных или частичных релизов могут производится одновременно. Это называется пакетным релизом. Релиз – это всегда достаточно существенное изменение в инфраструктуре. Суть этого процесса в том, что никакое изменение не может быть произведено в рабочей среде, пока оно не прошло тестирование и приемку, а инженеры поддержки и пользователи не прошли соответствующее обучение. Данный процесс состоит из 8 последовательных операций, для которых определены 3 сферы выполнения – среда разработки, среда тестирования и рабочая среда. Только по завершению всех операций в средах разработки и тестирования релиз попадает в рабочую среду. Управления релизами проходит под контролем процесса управления изменениями. Перечень операций процесса управления релизами: разработка политики процесса; планирование релиза; разработка, построение и конфигурирование релиза …………………………………………………………………….. …………………………………………………………………….. ……………………………………………………………………..
--------- Список использованной литературы
1. Ананьин В. И. Формирование архитектуры корпоративной информационной системы путем естественного отбора // Intelligent Enterprise. 2006. № 17 2. Ананьин В. И. Устойчивость управления ИТ-проектами в условиях неопределенности // Управление проектами. 2007. № 1, 2 (М., ИД Гребенникова). 3. Ананьин В.И. Стиль ERP-проекта, как фактор его успешности. Tadviser, Центр выбора технологий и поставщиков, 2007 г. (www.tadviser.ru/articles/16850/?phrase_id=69331). 4. Ананьин В. И. Границы применения сервиса. ITIL и ИТ-архитектуры // Intelligent Enterprise. 2008. № 2 (www.iemag.ru/articles/detail.php?ID=6503). 5. Алексенцев А.И. Сущность и соотношение понятий «защита информации», безопасность информации» и «информационная безопасность» // Безопасность информационных технологий. 2009. № 1. 6. Благовещенская М.М., Злобин Л.А. Информационные технологии систем управления. – М.: Высшая школа, 2008. 7. Бугорский В.И., Фомин В.И. Информационные системы в экономике: Основы информационного бизнеса. Учебное пособие. — СПб.: СПбГИЭА, 2007. 8. Баронов В.В., Каляное Г.Н. и др. Автоматизация управления пред приятием.— М.: Инфра-М, 2008. 9. Бойль Томас, Мировые информационные системы.- М.: Инфо, 2007. 10. Богданова Е.А., Информационные маркетинг. – Спб.: Альфа, 2008. Бройдо В.Л. Вычислительные системы, сети и телекоммуникации.- СПб.: Питер, 2007. 11. Годин В.В., Корнеев И.К. Управление информационными ресурсами. – М.: ИНФРА-М, 2008. 12. Голенищев Э.П., Клименко И.В. Информационное обеспечение систем управления. – М.: Феникс, 2008. 13. Гринберг А.С., Король И.А. Информационный менеджмент. – М.: Юнити, 2007. 14. Дж. Лодон, К. Лодон. Управление информационными системами. 7-е изд. – СПб.: Питер, 2006. 15. Журавленко Н.И. Концептуальные основы информационной безопасности. – Уфа, 2007. 16. Костров А.В. Основы информационного менеджмента. — М.: Финансы и статистика, 2005. 17. Карминский А., Нестеров П. Информатизация бизнеса. — М.: Финансы и статистика, 2007. 18. Николаева Т. Информационная экономика.—СПб.: НИИХ,СП6ГУ, 2008. 19. Поддубная Л.М. Компьютерная технология разработки тестовых заданий: Учеб. пособие. – М.: Логос, 2007. 20. Избачков Ю.С., Петров В.Н. Информационные системы. – СПб.: Питер, 2008. 21. Информационные технологии управления. / Под ред. Титоренко Г.А. М.: Юнити, 2006. 22. Муравьев В.А. Информация в постиндустриальной экономике // Вестник ФА, № 3, 2007. 23. Минцберг Г. Структура в кулаке. Создание эффективной организации. СПб.: Питер, 2008. 24. Степанова Е.Е., Хмелевская Н.В. Информационное обеспечение управленческой деятельности. – М.: Форум, 2006. 25. Тронин Ю.Н. Информационные системы и технологии в бизнесе. – К.: Знания, 2007. – 341с. 26. Устинова Г.М. Информационные системы менеджмента. – М.: Юнити, 2006. 27. Шеховцов М.В., Рынок информационных технологий. М.: Юнити, 2007. 28. Ширинский С.В. Конспект лекций по курсу «Новые Информационные Технологии». – М., 2008 г. 29. http://www.bytemag.ru/articles/detail.php?ID=6733 30. http://buk.irk.ru/chairs/management/samsonov.pdf 31. http://www.iemag.ru/master-class/detail.php?ID=15746 32. http://compress.ru/Archive/CP/2007/9/2/
