Как организовать надежную защиту коммерческих данных и при этом не сделать безопасность помехой на пути развития бизнеса? Как сохранить гибкость бизнес-процессов и выстроить прозрачную схему разделения ответственности между сотрудниками? Как разгрузить ИТ
Вершина пирамиды
В современных методах управления бизнесом процессный подход завоевал устойчивую позицию наравне с функциональным. Модель организации, в которой каждый отдел был ориентирован только на выполнение своих узкоспециальных задач (функций) и практически не координировал своих действий с остальными подразделениями, оказалась неэффективной. Поэтому внимание теоретиков и практиков управления было перенесено на определение сквозных бизнес-процессов, которые пронизывают всю организацию и направлены на достижение конечных бизнес-целей.
Участниками подобных бизнес-процессов становятся сотрудники, занимающие самые разные должности и работающие в самых разных подразделениях, а их полномочия (роли) могут существенно изменяться от задачи к задаче. Права и обязанности конкретных работников невозможно закрепить раз и навсегда. Они должны быть гибкими, «плавающими», легко настраиваемыми.
Кто такой владелец процесса | Naked BPM (Eng sub)
Как показывает практика, такой подход удобнее всего реализовать с помощью набора бизнес-ролей, который исчерпывающе описывает права и полномочия сотрудников, исходя из их функциональных обязанностей и места в организационной иерархии. Создание единой корпоративной модели бизнес-процессов и привязанных к ним бизнес-ролей дает полную картину разделения прав и обязанностей в компании, облегчает понимание и контроль сфер ответственности каждого руководителя и рядового сотрудника, позволяет гибко и прозрачно модифицировать их.
Как правило, проект внедрения корпоративной системы ролевого доступа (Enterprise Role Management) начинается с внедрения системы единой авторизации Enterprise Single Sign-on, которая позволяет сотруднику авторизоваться сразу во всех доступных ему системах, лишь один раз назвав свои логин и пароль. Следующим этапом становится внедрение инструментов Identity служба безопасности, которой необходимо гарантировать соблюдение нормативных требований; ИТ-служба, которая стремится распространить наработанный опыт управления доступом к информационным системам в масштабах всей компании. Но в первую очередь ролевая система выгодна топ-менеджменту, заинтересованному в четком и прозрачном распределении ответственности и централизованном управлении доступом к ресурсам, в том числе такому важному, как информация.
Помимо стратегических целей, внедрение ролевого доступа облегчает решение некоторых чисто тактических задач. Например, для компаний, участвующих в торгах на Нью-Йоркской бирже, система ролевого доступа облегчит прохождение ежегодных аудитов на соответствие требованиям закона Сарбейнса – Оксли, а для российских компаний — выполнение Федерального закона о защите персональных данных ФЗ-152.
Фактическая реализация подобных проектов может различаться, поскольку определяется во многом конечной целью проекта. Например, в компании «ВымпелКом» создание ролевой матрицы ответственности было обусловлено стремлением ИТ-департамента воплотить в жизнь уже частично реализованную концепцию процессного управления в части ИТ-поддержки бизнеса. У другого оператора связи заказчиками выступали службы ИТ и безопасности — соответственно, и система создавалась там с учетом требований организации доступа к ИТ-ресурсам.
Профессия — владелец бизнеса. Собственник бизнеса — отношения с менеджером. Николай Мрочковский.
Что касается экономического обоснования, то единственно правильным является взгляд с точки зрения бизнеса: если система тем или иным способом облегчает развитие компании, то ее целесообразность очевидна, а значит, тем быстрее удастся выделить средства и приступить к ее практической реализации.
Измеримая польза
Согласно отчету международной исследовательской группы META за 2008 год, в среднестатистической компании с численностью персонала порядка 10 тыс. человек около 48% запросов в службу поддержки связаны с проблемами предоставления доступа, получения паролей и прочими аналогичными задачами. Стоимость процессов по предоставлению доступа в крупной компании может превышать миллион долларов, и это свидетельствует о неэффективности существующих способов управления доступом «вручную».
Внедрение ролевой системы корпоративного уровня позволит охватить и автоматизировать, полностью или частично, все задачи управления доступом ко всевозможным ИТ-сервисам, начиная от организации рабочего места для нового сотрудника и заканчивая прохождением всего процесса согласования любых изменений в правах и полномочиях.
Эффективность системы ролевого доступа тем выше, чем большее число бизнес-приложений компании она охватывает. Кроме того, ролевой доступ позволяет разумно ограничить и права самих ИТ-администраторов, которые больше не смогут монопольно и бесконтрольно обращаться к базам данных и пользовательским каталогам.
Еще одной заметной статьей экономии, зависящей от внедрения ролевого подхода, является сокращение непрофильных для компании расходов, связанных с предотвращением утечки информации или ликвидацией ее последствий. Например, при обнаружении несанкционированного доступа к конфиденциальным данным клиентов компании пришлось бы не только срочно заняться поиском и ликвидацией «дыр» в сфере защиты информации, но и оповестить о неприятном инциденте своих клиентов (и значит, оплатить услуги контакт-центра), а также донести до рынка информацию о предпринятых мерах по ужесточению политики безопасности и восстановить репутацию фирмы (то есть провести специальную PR-программу, которая объяснит клиентам и партнерам, что было сделано во избежание подобных ситуаций в будущем). В реальности эти дополнительные расходы могут исчисляться миллионами долларов! Ролевой доступ позволяет ограничить область действий и тем самым снизить вероятность нелегитимных действий со стороны сотрудников.
Как это реализуется на практике
В идеале любой проект, связанный с построением ролевой модели, должен начинаться с анализа бизнес-процессов компании и выявления существующих, хоть и неформально, бизнес-ролей. Обследование ведется сразу с двух сторон: с позиций ИТ-службы и с позиций бизнеса.
С точки зрения бизнеса, именно владелец должен формировать список бизнес-ролей с понятным бизнес-контекстом (например, оператор контакт-центра, администратор СУБД и т. п.), а также контролировать процесс реализации этих ролей в информационных системах.
С точки зрения ИТ-службы, информационные системы уже содержат наборы преднастроенных пользовательских ролей, состоящих из перечня доступных функций (например, заведение нового клиента, формирование отчета, просмотр документа). Но эти наборы могут заметно отличаться в различных приложениях, что создает ИТ-службе дополнительные сложности при их формализации.
Аккуратное сопоставление ролевых моделей, предоставляемых ИТ-службой и владельцами бизнес-процессов, чаще всего становится самой сложной частью проекта. Фактически эта задача равнозначна переводу ролевых моделей с языка бизнеса на язык ИТ.
После того как точки соприкосновения ИТ и бизнеса найдены, можно переходить к следующему этапу — инвентаризации ролей. Для этого производится выгрузка соответствующих данных из службы каталогов, почтовой системы, кадровой системы, приложений для поддержки производственных процессов (например, для банка — это АБС, для телекома — биллинг и CRM). Процедура инвентаризации помогает выявить потенциальные лазейки, так называемые мертвые души (когда роль сотрудника сохраняется в системе даже после его увольнения), а также дополнить список ИТ-ролей.
Роли накладываются на организационную структуру компании и корпоративные бизнес-процессы, что дает в итоге полноценную трехмерную картину ситуации «как есть» (as is). Затем наступает черед нормализации данных — выявления закономерностей, унификации названий и т. п. После этого создается трансформационная матрица, она описывает те роли, которые следует удалить, создать или модифицировать, а также сотрудников, права которых следует урезать или, напротив, расширить. Этот список окончательно согласуется с владельцами бизнес-процессов и ИТ-администраторами, и в результате получается единая карта ролей и доступов — целевая картина (to be).
Данные карты ролей и доступов передаются в систему класса Enterprise Role Management (она позволяет создавать и изменять бизнес-роли, управлять ими, связывать их с информационными системами), а также в систему Identity Access Management окажутся в конце концов все информационные системы компании.
Ключевые советы:
Как известно, дьявол кроется в мелочах. Чтобы проект сложился максимально успешно, необходимо помнить о нескольких простых моментах:
- ролевая система управления доступом к ИТ-сервисам должна внедряться не одномоментно, а постепенно, последовательно охватывая одну информационную систему за другой;
- до начала проекта должны быть проведены максимально полный аудит и анализ существующих доступов и ключевых ролей;
- важнейшим условием создания эффективной системы является высокое качество данных, полученных от информационных систем и владельцев бизнес-процессов; не стоит жалеть времени на проверку собранной информации;
- при реализации практически любого инновационного проекта распространенной проблемой является внутренний саботаж; необходимо выявлять внутри компании заинтересованных лиц, которые станут движущей силой проекта, смогут предотвратить или ослабить сопротивление сотрудников, довести проект до конца.
Источник: www.osp.ru
Владельцы и менеджеры услуг в дикой природе
Все слушатели курсов «Основы управления ИТ-услугами» почти всегда тонко чувствуют терминологическое болото, в котором не-англоговорящим коллегам предлагается утонуть, буквально с первого дня знакомства что с сервисным, что с процессным подходом. Дело, наверное, в различных культурных установках, на которых и строятся языки. В любом случае, весь тяжелый словесный багаж может привести к разочарованию в ITSM.
Не расстраивайтесь, в жизни всё гораздо веселее, чем в универсальных сводах знаний.
Так вот, однажды я получил вопрос:
- владелец занимается целеполаганием и инвестициями в процесс и заинтересован в результатах процесса. «Надо выкопать канаву вооон от того забора до завтрашнего обеда»,
- менеджер процесса отвечает за реализацию целей: покупает лопаты, следит за тем, чтобы копатели не отлынивали от работы, и по часам контролирует наступление обеда.
- Общий термин для обозначения любого руководителя в организации поставщика услуг.
Правильный ответ, который может себе позволить осторожный тренер — это «бывает по-разному»;)
Неправильных, то есть практических, ответов существует несколько. Я знаю три, поделюсь в комментариях. А как бы ответили на этот вопрос вы?
Кто исполняет роли менеджера услуг и владельца услуг, и в чем состоят их обязанности?
Также по теме:
- Как соотносятся роли Service Owner и Service Level Manager
- Многоликий change manager
- Чем обеспокоены менеджеры ИТ-услуг? Пять главных причин
- Краткий видео-обзор курса «Управление уровнем услуг и каталогом услуг» (VAP-SLM)
- Лица каталога услуг
ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от соавторов ITIL 4
Узнать больше
Комментариев: 10
Grigory Kornilov
У нас под владельцем услуг подразумевают того, кто выбивает расходы из бюджетного распорядителя или является таковым. При этом бывает бизнес владелец (частная услуга — в основном услуга необходима для его бизнес процессов, бизнес задач), а выбает IT владелец (общая услуга — услуга необходима многимвсем в более-менее равной степени). Важно, чтобы расходы на сервис подтверждались приоритезированной потребностью перед общим бюджетированием компании.
Константин Нарыжный
Григорий, круто, это один из моих ответов. Но если говорить об ИТ-владельце: то кто же тогда менеджер?
Grigory Kornilov
Пример сервиса «электронная почта»: Владелец — руководитель IT (или где-то это руководитель инфраструктуры IT). Менеджер сервиса — «инфраструктурный» сервис менеджер или руководитель администраторов, отвечающих за Windows системы. При вырожденном варианте: владелец — руководитель администраторов IT группы, менеджер — администратор, который работает больше всего с почтой.
Дмитрий Исайченко
Владелец процесса — лицо, которое использует процесс, как управленческий инструмент. Менеджер процесса обеспечивает, чтобы этот инструмент работал. И мне кажется такая аналогия с процессами очень уместна. Но её применение к сценариям «внутренний поставщик» и «коммерческий поставщик» даёт разные результаты. Для внутреннего поставщика аналогия такова.
Владелец услуги — это заказчик (он использует услугу для решения своих задач, они определяют требования к ним). Если заказчиков несколько, то «главный заказчик», но чтобы раскрыть этот термин надо смотреть на конкретную ситуацию. Менеджер услуги — ответственный со стороны поставщика, который обеспечивает предоставление этой услуги.
Для коммерческого поставщика всё немного по-другому, поскольку владельцами услуг здесь фактически являются коммерческие структуры на стороне поставщика (они используют услуги для заработка денег, они и определяют требования к ним). А менеджер — это производство. Поэтому получается, что применение «процессной» аналогии здесь требует некоторой осторожности.
Константин Нарыжный
Дмитрий, под «коммерческими структурами» вы понимаете сейлзов? Мой второй ответ, именно для внешних поставщиков услуг был такой: владельцем услуги является представитель собственников, отвечающий за то или иное направление бизнеса: консалтинг, аутсорсинг мощностей, аутстаффинг, поддержка оборудования и т.п. А менеджерами услуг — и я таких видел — являются энергичные ребята, которые сидят на территории заказчика и отвечают за обслуживания конкретного контракта.
Дмитрий Исайченко
Константин Нарыжный
Дмитрий, в каждом диалоге с вами я чувствую что путаюсь;) Всё же я говорю про ребят, которые действительно рубят в технологиях и в самом простом случае работают первой линией, маршрутизирующей инциденты среди специалистов-технарей в своей компании. Кроме того, их иногда вызывают для консультаций по оценке изменений. А в одной компании такой менеджер услуги даже был участником внутреннего CAB, если изменение касалось «его» куска инфраструктуры. Заметьте, что такие «детали» врядли интересуют «владельца», который проектирует общую услугу, предоставляемую многим заказчикам.
Дмитрий Исайченко
«Дмитрий, в каждом диалоге с вами я чувствую что путаюсь» Ну. я же просто вопрос задал. Вы ответили, спасибо
phantom
Можно расшифровать определение Владельца услуги? они. к ним. я про тезис в скобках: Владелец услуги — это заказчик. он использует услугу для решения своих задач, задачи определяют требования к услугам. это имелось в виду?
Евгений
Дмитрий, как может владелец=заказчик?! Даже в случае внутренних взаимодействий, владелец (owner) — это тот, кто отвечает за предоставление услуги всецело заказчику. А заказчик — это как правило бизнес ф-ия, которая использует услугу для своих бизнес целей.
Источник: cleverics.ru
Светлана Бова, Chief Data Officer банка ВТБ — о главных вопросах и ошибках в управлении данными
Актуальность темы управления данными (Data Governance) растет с каждым годом. Действительно, необходимость организации процессов, направленных на повышение эффективности сбора, обработки, хранения и использования данных как ценного актива, уже очевидна практически всем компаниям. Много сказано о том, какие преимущества приносят компании правильно выстроенные процессы управления данными, и многие организации уже начали внедрение этой инициативы. При этом организации часто допускают похожие ошибки, которые негативно влияют на темпы внедрения и эффективность создаваемых процессов управления данными. О том, какие это ошибки, как их избежать и на какие вопросы организация должна найти ответы в процессе внедрения Data Governance, в материале, подготовленном для TAdviser, рассказывает Светлана Бова, Chief Data Officer банка ВТБ.
Зачем компании управление данными?
Светлана Бова: ни в коем случае нельзя пытаться сразу улучшить качество всех данных в организации
Иногда организация начинает внедрение процессов управления данными, не понимая конечных целей и измеримых показателей их достижения. Также отсутствует оценка текущего уровня зрелости организации в части управления данными и стратегия развития функции.
Инициатива может быть продиктована внешними факторами, такими как общий тренд на цифровую трансформацию, внедрение процессов управления данными в компаниях конкурентах («у них есть, нам тоже нужно»), при этом внутренние предпосылки отсутствуют или непрозрачны для руководства компании. Таким образом, происходит попытка внедрения того, к чему компания не готова. Более того, возможно компании это и не нужно именно в настоящий момент. Естественно, перспективы становятся довольно туманными.
Как этого избежать?
Необходимо ставить четкие и измеримые бизнес — цели. Например, повысить эффективность маркетинговых компаний на 10% за счет повышения качества клиентских данных, снизить на 30% расходы на внедрение ИТ-систем за счет описания архитектуры данных организации, снизить на 50% трудозатраты на проверку финансовой и рисковой отчетности за счет унификации бизнес-терминов и создания централизованной витрины данных и т.д. Эти цели должны быть понятны, подтверждены бизнес-подразделениями и руководством компании и отражены в стратегии управления данными.
С чего начать?
Стоит отметить, что ни в коем случае нельзя пытаться сразу улучшить качество всех данных в организации или описать в бизнес-глоссарии все термины, используемые в компании. Относительно управления данными, можно сформулировать принцип Парето следующим образом: «20% всех данных критически влияют на 80% бизнес-процессов компании».
Правильным подходом в данном случае будет следующая последовательность шагов:
Необходимо выявить самые критичные с точки зрения бизнеса процессы, определить данные, существенно влияющие на эффективность этих процессов, зафиксировать начальную оценку эффективности процессов. Далее последовательно шаг за шагом повышать уровень качества, доступности данных и описания их метаданных. По завершении работ оценить, насколько удалось достичь заявленных бизнес–целей и переходить на активности по следующему бизнес-процессу, масштабируя таким образом деятельность по системной работе с данными.
Что главное в управлении данными?
Существует некий стереотип, что внедрения дорогостоящих ИТ-систем достаточно, чтобы навести порядок в данных. То есть, если внедрить, например, промышленное хранилище данных, Big Data или инструменты управления данными, то с данными все сразу станет хорошо. По моему опыту, это не так. Практически каждый, кто имел дело с качеством данных, знает о принципе GIGO (garbage in — garbage out). Этот принцип говорит о том, если в точку входа в ИТ-систему поступают некорректные данные, то на выходе результат будет бесполезен, даже если внутри ИТ-системы все алгоритмы отработали корректно.
Поэтому я выделяю следующие в порядке значимости приоритетные направления работ по управлению данными:
- Люди – самый важный ресурс. У сотрудников должна появиться культура работы с данными, осознание того, что данные – это ценный актив, с помощью которого компания может получать дополнительную прибыль или сокращать издержки, и желание быть владельцами данных.
- Процессы, регламентирующие сбор, обработку, хранение, использование данных, работы по повышению качества данных и ведению глоссария бизнес-терминов компании, архитектурные стандарты, институт владения данными и так далее.
- Технологии: бизнес-глоссарий, инструментарий управления потоками данных (Data Lineage), инструменты интеграции, проектирования моделей данных, программное обеспечение по управлению качеством данных, системы управления мастер-данными (MDM — Master Data Management) и системы управления нормативно-справочной информацией (RDM — Referential Data Management).
Конечно, технологии необходимы, но все же они вторичны по отношению к людям и организации процессов.
Кто такой владелец данных?
Бывает, что менеджмент организации считает управление данными технологической инициативой. Данные хранятся в ИТ-системах, это означает, что и отвечать за них (владеть ими) должны ИТ-специалисты. Это в корне неверное утверждение.
Также часто применяется концепция, когда владельцами данных назначаются подразделения, использующие данные в своих процессах, например, для подготовки финансовой отчетности. То есть данными владеет тот, кто больше всех заинтересован в их качестве. Такой подход возможен, но все же он не является достаточно эффективным.
Если, например, потребитель покупает в магазине некачественный товар, кому он предъявит претензии? Конечно производителю товара. Так и с данными: ими может владеть только тот, кто их создает, тот, в чьем процессе данные рождаются на свет, тот, кто может непосредственно влиять на эффективность процесса производства данных. В том числе регламентировать процессы ввода данных в ИТ-системы, процессы контроля качества данных, как автоматизированные, так и ручные, инициировать необходимые доработки ИТ-систем.
Каким должен быть CDO?
CDO считается тяжелым профилем кандидатов для поиска и найма, и этому есть несколько причин: во-первых, в России практика выделения деятельности по управлению данными в отдельную функциональную единицу организации существует не так давно, во-вторых, пока не выстроен учебный институт по данной профессии в отличии от мирового сообщества, в-третьих, не накоплена статистика успешных людей на данной позиции, именно поэтому так неоднозначно и затруднительно бывает составить требования к кандидату на позицию лидера по управлению данными в каждой конкретной организации.
Иной раз, компания определяет для себя, что технические компетенции являются основными для директора по данным. Да, технические компетенции нужны, в том числе и знания в области хранилищ данных, инструментов преобразования данных, навыки проектирования и так далее. Но, мировые практики доказывают, что гораздо важнее другое.
CDO – это прежде всего стратег, который определяет стратегию компании по работе с данными. CDO – это бизнесмен, который креативно предлагает бизнесу пути повышения эффективности процессов за счет управления данными. И в конце концов, CDO – это миссионер, задача которого обратить каждого в организации в свою веру: веру важности данных как ценного актива.
Поэтому основные необходимые CDO компетенции можно представить следующим образом в порядке значимости:
- Высокий уровень коммуникативных навыков, включая эмоциональный интеллект, харизма;
- Стратегическое мышление, умение внедрять инновации;
- Знание предметной области и бизнес-процессов компании;
- Технические компетенции.
Когда заканчивается инициатива по управлению данными?
Существует мнение, что управление данными это конечный проект, разовое упражнение по очистке и инвентаризации данных. Однако это не так. Мир вокруг стремительно меняется, данные исчезают и появляются, мигрируют информационные системы, меняются требования к данным.
Поэтому после внедрения Data Governance фреймворка работы по управлению данными должны быть продолжены в регулярном ежедневном режиме в рамках операционной деятельности компании. Непрерывная работа по совершенствованию сбора, обработки, хранения данных, повышению их качества и проникновению идеи ответственного к ним отношения становится неотъемлемой частью жизни и культуры компании. Только тогда можно смело говорить об успехе внедрения инициативы по управлению данными.
Смотрите также
- Директор по данным (Chief Data Officer, CDO)
- Директор по цифровым технологиям Chief Digital Officer, CDO
- ИТ-директор (CIO — Chief Information Officer)
- Директор по информационной безопасности (Chief information security officer, CISO)
- Финансовый директор (CFO — Chief Financial Officer)
- Системный администратор
- Специалист по изучению данных (data scientist)
Источник: www.tadviser.ru