Главная страница

Лекции грант. Лекции_грант. Курс лекций РостовнаДону 2007


Скачать 1.36 Mb.
НазваниеКурс лекций РостовнаДону 2007
АнкорЛекции грант
Дата21.02.2023
Размер1.36 Mb.
Формат файлаpdf
Имя файлаЛекции_грант.pdf
ТипКурс лекций
#949405
страница2 из 15
1   2   3   4   5   6   7   8   9   ...   15
1.2 Функциональные области управления службой ИС
Информационная система предприятия предназначена для информаци- онной поддержки бизнес-процессов.
В наши дни основой успешного бизнеса является бесперебойное функ- ционирование информационных систем, обеспечивающих конкурентоспособ- ность и прибыльность компании Основная задача службы ИС − обеспечение бизнес-процессов информационным обслуживанием заданного качества с ис- пользованием соответствующих информационных технологий. Поддержка ин-

12
формационных процессов осуществляется посредством ИТ-сервисов с задан- ными характеристиками.
Служба ИС предприятия, как правило, организует свою работу по четы- рем функциональным направлениям [3]:
− планирование и организация;
− разработка, приобретение и внедрение;
− предоставление и сопровождение ИТ-сервиса;
− мониторинг.
В рамках направления «Планирование и организация» решаются задачи разработки стратегии в области ИТ, координации развития ИТ организации, планирования ресурсов службы ИС (бюджет, человеческие ресурсы, внешние услуги и др.), управления рисками, управления качеством.
Основной задачей направления «Разработка, приобретение и внедрение»
− внедрение новых ИС.
Функциональное направление «Предоставление и сопровождение серви- са ИТ» обеспечивает формализацию требований подразделений-заказчиков к
ИТ-сервисам, согласование требований к сервисам с соответствующими ресур- сами службы ИС и предоставление конечным пользователям сервисов ИТ, со- ответствующих согласованным требованиям.
Основная задача направления «Мониторинг» − аудит процессов службы
ИС.
Организационная структура службы ИС зависит от многих факторов:
− масштаб службы ИС − более крупные службы ИС обычно имеют более сложную и разветвленную организацией! структуру;
− отраслевую принадлежность, с которой связано наличие или, на- против, отсутствие определенных структурных подразделений;
− распределение организации по территории − наличие территори- ально удаленных подразделений и филиалов существенно меняет организационную структуру службы ИС.

13
Этот перечень отнюдь не исчерпывающий, в него входят и другие факто- ры, например состав используемых в организации ИС.
Для малых предприятий организационная структура службы ИС, описан- ная в [3], представлена на рис. 1.2.
Функции планирования в ней выполняются руководителем службы ИС.
Именно по этой причине такая структура пригодна только для службы ИС не- большого размера − в более крупных службах ИС объем работ по планирова- нию требует обособления отдельных функций планирования.
Директор ИС
Управление разработки
Отдел мониторинга
Управление сопровождения
Отдел ЛВС
Отдел связи и телекоииуникаций
Отдел распределенных систем
Отдел распределенных систем
Отдел офисных приложений
Отдел офисных приложений
Рис. 1.2. Пример плоской структуры службы ИС
Непосредственно подчиняются директору ИС управление разработкой, выполняющее функции разработки, приобретения и внедрения информацион- ных систем, и управление сопровождением, выполняющее функции предостав- ления и сопровождения ИТ-сервисов. Организационное разделение разработки и эксплуатации имеет принципиальное значение. Успешная эксплуатация ИС в течение сколько-нибудь длительного времени возможна лишь тогда, когда она не требует постоянного вмешательства разработчика. Это обеспечивается со- блюдением существующих методологий разработки и тестирования ИС, а так- же надлежащей пользовательской и эксплуатационной документацией. Тести- рование ИС и документации на нее на соответствие требованиям устойчивой эксплуатации обеспечивается в ходе передачи системы в эксплуатацию. Этот

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

15
необходимости расширить управление разработкой за счет одного или несколь- ких менеджеров проектов.
В управлении сопровождением выделяют группы специалистов сходной квалификационной базы. Отделами, состоящими из сотрудников сходной ква- лификации, проще управлять, поскольку однородность упрощает найм персо- нала, диспетчирование работ, бюджетирование и др. Типичный набор отделов в управлении сопровождением в плоской структуре включает отдел ЛВС (ло- кальной вычислительной сети), отдел распределенных систем, отдел связи и те- лекоммуникаций, отдел офисных приложений. Первый отдел осуществляет поддержку локальной сети, включая сервер и его ОС, второй − поддержку рас- пределенных систем, например бухгалтерской, третий − связь, телефонизацию и доступ в Интернет, четвертый − поддержку оборудования рабочих мест − компьютеров, принтеров и т.д., а также офисных приложений.
Функции мониторинга в плоской структуре выполняет отдел мониторин- га (Service Desk), непосредственно подчиненный директору ИС. В этот отдел поступают сообщения пользователей об инцидентах, он же сообщает об инци- денте соответствующим отделам службы сопровождения и контролирует ход работ по разрешению инцидента. Наконец, в этом отделе накапливается боль- шой объем статистики инцидентов и времени их разрешения. Функции монито- ринга более высокого уровня − контроль планов работ, графиков проектов, бюджета службы ИС в целом и отдельных ее подразделений − выполняет ди- ректор ИС.
Увеличение размера организации и объема работ службы ИС ведет к ус- ложнению её организационной структуры. В этом случае могут применяться развернутые и дивизиональные структуры службы ИС.
Функциональная модель управления и основанная на ней организацион- ная структура службы ИС длительное время представляли собой основной и единственный подход к управлению в этой области. Однако со временем вы- явился ряд ограничений функционального подхода, снижавших эффективность управления службой ИС.

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

17
пользователям, шифрование данных и т.д. Наконец, на этапе эксплуатации сер- виса осуществляются обучение пользователей и контроль выполнения требова- ний безопасности на рабочих местах конечных пользователей.
Масштаб сервиса определяется на этапе планирования сервиса в рамках функции планирования сервиса ИТ. Если некие сервисы ИТ реализуются со- вместно в рамках общего проекта, эти сервисы должны планироваться совмест- но. Обеспечение доступа к ИТ-сервису на всех серверах и рабочих местах реа- лизуется в рамках функций приобретения, разработки и внедрения. Изменения масштаба сервиса контролируются в рамках функций планирования и органи- зации.
Цена ИТ-сервиса определяется в процессе планирования сервиса. На эта- пе разработки и внедрения ИТ-сервиса контролируется выполнение бюджета соответствующего проекта и уточняется сумма первоначальных затрат на при- обретение и/или разработку и внедрение. На этапе эксплуатации контролирует- ся величина текущих затрат на сервис и их соответствие бюджету организации.
Таким образом, между функциями службы ИС и параметрами ИТ- сервиса нет прямого и однозначного соответствия. Качество ИТ-сервиса в це- лом и каждый параметр сервиса ИТ в частности определяются несколькими функциями ИТ. Одна и та же функция службы также может относиться к не- скольким сервисам ИТ или даже ко всем сервисам ИТ, существующим в орга- низации. Это обстоятельство создает для управления службой ИС, организо- ванной по чисто функциональному принципу, целый ряд проблем.
Во-первых, обеспечение конечного результата − качества ИТ-сервиса − требует координации различных функций службы ИС. В ряде случаев эту коор- динацию может осуществить вышестоящий руководитель. Однако многие зада- чи по такой координации требуют полномочий высокого уровня, вплоть до уровня директора ИТ. В результате руководители высокого уровня оказывают- ся перегруженными большим потоком задач, не имеющих отношения к их по- стоянной деятельности и непосредственным обязанностям.

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

19
Процесс подразумевает наличие цели, критерия результата, ресурсов и определенной последовательности работ (т.е. шагов процесса). Применительно к процессам службы ИТ целью является предоставление заказчику ИТ-сервиса приемлемого уровня качества. Эта общая задача может быть разделена на две более частных:
− определение и согласование параметров ИТ-сервиса;
− обеспечение соответствия фактических параметров ИТ-сервиса дос- тигнутым соглашениям.
Каждая из этих целей, в свою очередь, распадается на несколько целей следующего порядка, каждой из которых соответствует свой процесс.
Управление процессами предполагает следующие шаги:
− определение цели процесса и показателей достижения этой цели
(количественных или качественных);
− назначение ответственного за процесс, задачей которого является достижение цели процесса;
− регламентация процесса в целом и составляющих его работ;
− при необходимости − автоматизация процесса посредством инстру- ментальных средств, разработанных в самой организации либо за- купленных извне.
Проблемы ответственности за результат процесса и координации разре- шается в явном виде посредством назначения ответственного лица – менеджера процесса. Проблема единой «точки контакта» также вполне разрешима в рам- ках регламента процесса, обязательного для всех сотрудников службы ИС неза- висимо от их функционального подчинения.
Управление процессами изменяет лишь управленческие функции службы
ИС, не затрагивая функции собственно разработки и сопровождения ИТ- сервисов. Изменения состоят в систематическом целенаправленном решении задач координации функций в ходе выполнения процессов службы ИС. Для этого достаточно формализовать соответствующий процесс, т.е. назначить ме- неджера процесса, определить роли участников процесса и установить правила

20
его выполнения, т.е. последовательность выполнения операций процесса, обя- занности в рамках ролей, правила эскалации и т.д.
Как следствие переход к процессной модели управления обычно не тре- бует ни дополнительного персонала, ни изменений в организационной структу- ре. Участники процесса выполняют свои должностные обязанности в рамках существующей организационной структуры; часть этих обязанностей, относя- щаяся к данному процессу, формализована в виде ролей процесса. Если все процессы службы ИС формализованы, то совокупность ролей совпадает с должностными обязанностями сотрудника (рис. 1.3).
Процессы
Рис. 1.3. Процессы, функции, роли в процессной модели управления
В такой системе менеджер процесса является начальником без подчинен- ных: он координирует деятельность не подчиненных ему сотрудников, относя- щихся к различным подразделениям существующей организационной структу- ры. Сам менеджер процесса тоже имеет должность в рамках существующей ор- ганизационной структуры.
Использование процессов в рамках существующей функциональной структуры весьма удобно. В ходе работы по этой схеме процессная модель и функциональная структура организации взаимодействуют между собой и уси- ливают преимущества друг друга.

21
Совместное использование обеих моделей также упрощает внедрение процессной модели. Процессная модель влияет не на полномочия функцио- нальных менеджеров, а на формы осуществления этих полномочий. Процесс- ные менеджеры принимают на себя задачу координации функций, которая в чисто функциональной модели решается на излишне высоком уровне.
Переход к процессной модели можно осуществить двумя путями:
− первый состоит в формализации опыта данной организации;
− второй предполагает использование передового опыта управления службой ИС, который реализован в типовых моделях бизнес- процессов этой службы.
На сегодняшний день общей методологической основой таких моделей является подход ITIL/ITSM, основанный на сборе и систематизации передовой практики управления службой ИС в течение последних 20 лет.
Использование типовых моделей бизнес-процессов службы ИС имеет це- лый ряд преимуществ.
Во-первых, типовая модель представляет в концентрированном виде опыт управления службой ИС в тысячах и даже десятках тысяч компаний. Со- ответственно, отказ от использования этого массива знаний по меньшей мере нецелесообразен.
Во-вторых, переход к процессной модели управления для всех задач службы ИС одновременно, в рамках одного проекта маловероятен. В этом слу- чае процессная модель дает менеджеру образ будущего, который становится ориентиром в ходе отдельных шагов внедрения.
В-третьих, типовая модель процессов службы ИС всегда опирается на не- кую систему понятий, на некий язык. Использование этого языка значительно облегчает достижение взаимопонимания участников процесса.
В-четвертых, типовая модель процессов поддержана разработчиками программного обеспечения автоматизации управления службой ИС и инфра- структурой ИТ. В результате программное обеспечение реализует именно эти

22
процессы. Реализация собственных процессов потребует разработки собствен- ного ПО.
Наконец, стандартная модель процессов обычно внедряется во многих организациях. В результате образуется сообщество пользователей, которое яв- ляется ценным источником информации по внедрению модели.
В данной теме были рассмотрены основные понятия ИТ-менеджмента,
ИТ-сервиса, характеристики ИТ-сервиса, основы процессной модели управле- ния ИС-службой в ее взаимосвязи с ИТ-сервисами, с одной стороны, и функ- циональной моделью − с другой.
1   2   3   4   5   6   7   8   9   ...   15


написать администратору сайта