Сначала я два года ленился узнать, кто такой HR бизнес-партнёр, потом полгода я ленился написать эту статью. Но одно событие взволновало меня, и вот пишу.
Обычные кадровики
Жили-были кадровики, работали в отделах кадров, занимались своими кадровыми делами: искали кандидатов на вакансии, вели кадровое делопроизводство, выдавали трудовые книжки сотрудникам, которые «решили отправиться исследовать новые возможности», — нормально трудились.
«А. решил отправиться исследовать новые возможности», — так в компании N сообщили об увольнении одного из руководителей.
Примем во внимание, что и поиск кандидатов, и приём на работу, и увольнение — всё это стандартные запросы, т.е. на вопрос, был ли у кадровиков каталог услуг, ответ строго утвердительный.
Вспомним, что параметры некоторых из кадровых услуг не просто существуют, но ещё и контролируются государством, значит и контроль исполнения SLA налицо. Вывод: можем говорить о наличии процесса управления уровнем услуг.
Управление конфигурациями? Учёт сотрудников такой, что не всякая CMDB сравнится по количеству атрибутов и точности информации.
А что такое испытательный срок, как не время от внедрения изменения до его оценки (PIR)? Значит, и управление изменениями тоже было.
К чему клоню: задолго до того, как ИТ-службы узнали про Айтиль, кадровые службы уже работали по-айтилевски.
Великий кадровик
Однажды некий кадровик задумался, а правильно ли кадровики живут. Не лучше ли будет, если вместо выполнения входящих запросов в точности в том виде, в каком они пришли, кадровики будут исполнять их так, как лучше для бизнеса.
Например, просят айтишники нанять ещё 10 человек на 1-ю линию, потому что инциденты в срок не успевают решать, а кадровик, думающий о том, как лучше для бизнеса, им говорит: «У вас слишком много инцидентов. Надо не первую линию раздувать, а процесс управления проблемами налаживать. Поэтому вместо 10 человек на 1-ю линию я вам найду, троих, а ещё двоих найду таких, которые сделают так, чтобы инцидентов меньше стало. Само собой разумеется, что все вопросы, связанные с изменением внутренних процессов, процедур и оргструктуры, я, конечно же, решу сам. Ведь я же не просто кадровик, я думаю об интересах бизнеса.»
Когда кадровик так думает и делает, из обычного кадровика он превращается в HR бизнес-партнёра.
IT бизнес-партнёр
Аналогию и последствия для сотрудников ИТ-подразделений вы уже поняли: думай об интересах бизнеса, и ты уже не просто айтишник, ты — IT бизнес-партнёр.
Несмотря на то, что поиск по словам «IT бизнес-партнёр» выдаёт несколько ссылок, а на «Хэд-хантере» уже есть вакансии на такую должность, очевидно (особенно, если сравнить те две вакансии с «Хэд-хантера» друг с другом), что никакого общепринятого значения у термина «IT бизнес-партнёр» ещё не сложилось. Сформулируем, как должно быть.
- IT бизнес-партнёр — классный термин. Он показывает, к чему надо стремиться: помни о потребностях бизнеса, стремись принести бизнесу пользу. Да, в Айтиле написано про выявление и удовлетворение потребностей бизнеса, но 90 % ИТСМ-проектов все ещё начинаются с управления инцидентами, а не со стратегии или каталога услуг.
- Нельзя называть должность «IT бизнес-партнёр». Это самое плохое, что можно сделать с этим понятием. Если такой должности не будет, то каждый сотрудник ИТ-подразделения сможет быть IT бизнес-партнёром, то есть помнить об интересах бизнеса. Но если назвать должность «IT бизнес-партнёр», то сотрудники всех остальных должностей получат индульгенцию об интересах бизнеса не думать — ведь есть специально нанятые для этого люди. А специально нанятых людей будет очень мало. Проверим по «Хэд-хантеру»: «Сбертех» искал ровно столько же «партнёров», сколько искал X5 — одного.
- Лучше писать «IT бизнес-партнёр», чем «ИТ бизнес-партнёр», потому что уже принято писать «HR бизнес-партнёр». Однообразие удобно.
- Пусть «IT бизнес-партнёр» станет наградой, которую бизнес присуждает ИТ-сотруднику. Совершенно нормально, если эту награду смогут получить все сотрудники ИТ, это не приз в соревновании, когда первое место может занять только один. Наоброт, это что-то вроде аттестата зрелости, без которого на работу вообще не берут.
Источник: konakov.biz
Партнёрство в ИТ: как выстроить эффективную работу
Партнёрская сеть — эффективный способов продвигать на рынке продукцию компании-производителя. Антон Мартынов, директор по работе с партнерами Arenadata, рассказал о принципах работы ИТ-вендоров с интеграторами, которые позволяют создать синергию
Общие цели и договоренности «на берегу»
- решить задачу клиента;
- выполнить обязательства в полном объеме;
- заработать.
Как правило, партнёры хорошо понимают специфику бизнеса конечных заказчиков, их «боли», потребности и могут эффективно внедрять различные решения в ИТ-ландшафт клиента. Иногда интеграторы создают собственные вертикальные отраслевые решения на базе стека технологий вендора.
Несмотря на выраженную специализацию, на рынке нередко бывают ситуации, когда конечный заказчик не понимает, зачем вендору нужен партнёр для интеграции и какую добавочную стоимость несет это сотрудничество. Кроме того, есть разные финансовые модели партнёрства и «поле», где компетенции разработчика исходного решения и интегратора пересекаются, а значит есть опасность, что границы персональной ответственности будут размыты.
Поэтому любое сотрудничество должно начинаться с ответов на эти вопросы. Есть три основных направления, по которым важно договориться с партнёром «на берегу»:
1.Конкретизация ролей в проекте
Необходимо проговорить, какой вклад каждый партнёр вносит в проект, в чем ценность партнёрства для конкретного заказчика и почему такой подход более оправдан, чем прямое взаимодействие клиента с вендором.
2. Выбор экономической модели и распределение ответственности
На рынке возможны разные варианты получения дохода в проекте: продажа лицензии, услуг по кастомизации, интеграции или технической поддержки и т.д. Важно на старте договориться, кто и на чем зарабатывает. Исходя из выбранной модели, описать зоны ответственности и конкретные обязательства каждого партнёра в проекте.
3. Размер стартовых инвестиций и сроки реализации проекта
Здесь важно обсудить все о необходимых инвестициях в проект, возможных рисках и сроках реализации. Поскольку в ИТ-бизнесе период от подготовки сделки до получения прибыли может занимать от шести месяцев до нескольких лет, важно, чтобы партнёры отдавали себе в этом отчет и были готовы финансировать все работы по проекту. В затратной части могут быть расходы на обучение персонала, производство маркетинговых материалов, pre-sale, производство пилотного проекта и другое.
Доверие и погружение партнёра в бизнес
Важно погрузить партнёра в специфику бизнеса с первых дней проекта. Чем выше степень этого погружения, тем более гибкой и эффективной будет команда, особенно когда перед ней встают нестандартные задачи.
- понимать бизнес-процессы компании-партнёра;
- иметь представление о скорости согласования конкретных решений или сопроводительной документации;
- знать особенности взаимодействия с конкретными людьми, принимающими решения.
Когда бизнес-процессы партнёра прозрачны, можно правильно планировать свои действия и формулировать заказчику выполнимые обещания.
Но в любом проекте всегда возникают непредвиденные ситуации, когда решение нужно принимать быстро, сообща и в условиях ограниченных ресурсов. Доверие и отличное понимание особенностей друг друга в этом случае имеют огромное значение и влияет на результат работы в экстремальных ситуациях.
Контрольные точки и обратная связь
Третье значимое звено в построении эффективной работы с партнёрами — это анализ промежуточных результатов.
- оба партнёра действовали в единой системе координат;
- ясно представляли себе общие контрольные точки проекта;
- синхронизировано проводили ретроспективу.
Все перечисленные факторы имеют большое значение не только с точки зрения выполнения KPI конкретного проекта, но и с позиции взаимного развития партнёров. В хороших проектах — это обязательная составляющая. Благодаря экспертизе интегратора, вендор дорабатывает функционал своего продукта с учетом требований конкретных отраслей бизнеса, а также расширяет границы своего присутствия на рынке. В свою очередь, благодаря тому что вендор предлагает широкий пул надежных инструментов и вкладывается в развитие продукта, интегратор наращивает собственную техническую экспертизу и увеличивает потенциальный спектр задач, которые он может решать для клиентов.
Довольный заказчик и взаимное развитие — две стороны синергии партнёрства в ИТ.
Источник: arenadata.tech
Бизнес-партнер для ИТ: роскошь или необходимость?
Все чаще в наше время встречаются специалисты с должностью «бизнес-партнер» в области ИТ, но далеко не все представляют, кто эти люди, чем они занимаются и что они должны делать. Людмила Бабикова, бизнес-партнер Розничного бизнеса Банка УРАЛСИБ, предлагает разобраться пошагово в этом вопросе.
Бизнес-партнер – кто это?
«Бизнес-партнер» (далее БП) или «менеджер изменений» – это сотрудник, который должен управлять полным скоупом ИТ-задач выделенного подразделения со стороны Заказчика. Как правило, БП является «единым окном» поступления задач в ИТ от выделенного вида бизнеса.
«Единое окно» создается с определенной целью. В одном виде бизнеса работает большое количество людей в различных отделах, каждый из которых может стать заказчиком ИТ-задачи. Одновременно с этим, ИТ-задачи, поступившие от одного вида бизнеса реализовываются, как правило, одними и теми же ресурсами в ИТ.
Внимание вопрос: если у одного ИТ-ресурса выстраивается очередь задач с одинаковыми сроками исполнения, то как ИТ принимает решение что делать сначала? Задачу отдела «А», потому что она пришла позже или задачу отдела «Б», потому что заказчик громко заявляет о ее важности.
Решение данного вопроса переходит из зоны ответственности ИТ в зону ответственности БП – именно он выстраивает сквозной приоритет очередности выполнения задач своего вида бизнеса. Т. е. если раньше в ИТ могла поступить задача от любого сотрудника отдела (или от руководителя среднего звена), то при наличии БП в организации любая задача любого сотрудника должна пройти проверки, которые задал БП, например: проверка расчета экономического эффекта от доработки, согласованность бизнес требований с профильными подразделениями, определение реальной необходимости реализации, наличие критериев приемки и проч. После пройденных проверок БП определяет сквозной приоритет задачи и согласовывает срок реализации с ИТ. Далее, БП осуществляет контроль реализации задачи в срок.
Еще одной функцией БП является выстраивание правил взаимодействия с ИТ. Например, заказчика не устраивает информирование о доработках в системе только в день наката на бой. Задача БП в данном случае проработать с ИТ оптимальную схему информирования заказчика о доработках, которые планируются для включения в следующий релиз системы, а так же последовательность действий каждого из участников в случае, если доработка не прошла одно из тестирований перед выводом «в бой», с последующем заключением SLA с ИТ по согласованной схеме.
Так же БП решает задачи с заказчиками по запросу от ИТ. Например, организация тестирования задач со стороны заказчика в короткий срок. В данном случае БП должен включить в мотивацию сотрудников со стороны заказчика KPI срока тестирования ИТ-задач заказчиками, а также предоставление инструмента для контроля и возможности тестирования (в т. ч. оперативное обеспечение сред тестирования).
Задача БП – выстроить эффективный бизнес процесс поступления и реализации задачи таким образом, чтобы «в бой» попадали только нужные бизнесу ИТ-доработки и в максимально короткий срок.
В чем ценность бизнес-партнера для организации?
БП должен понимать эффективность реализации задачи и уметь “отсеивать” ненужное. Мелкие “доделки”, за которые так сильно переживают заказчики, засоряют пропускную способность ресурсов ИТ, что негативно сказывается в целом на бизнесе ввиду невозможности оперативного создания продуктов или автоматизации процессов. Например, лучше на этапе инициации ИТ-задачи, отказать в 2-3 мелких «доделках» текущего процесса выдачи кредита, посмотреть на бизнес-процесс комплексно и сделать одну емкую автоматизацию, которая поспособствует уменьшению времени выхода на сделку и принесет по-настоящему значимый результат организации. Хорошая работа БП – это выявление и последующий «выброс в корзину» неэффективных ИТ-задач. Кстати, задача может стать неэффективной пока находилась в очереди на исполнение – БП должен вовремя ее идентифицировать и снять с реализации, не взирая на эмоциональную привязанность к задаче заказчика (заказчик мог долго и многоитерационно создавать бизнес-требования, из-за чего ему «жалко» снимать с реализации задачу).
БП должен понимать бизнес процессы организации, чтобы совместно с заказчиком прорабатывать “облегчение” бизнес требований без потери эффекта от доработки. Таким образом ресурс ИТ высвободится от реализации “излишних” бизнес-требований.
БП должен уметь выстраивать коммуникации внутри бизнеса и внутри ИТ, т. к. сквозной приоритет задач для ИТ должен быть непротиворечив и прозрачен для всех сторон. При наличии БП в организации, ИТ имеет на руках всегда актуальные ожидания заказчика по срокам и очередности ИТ-задач, что способствует качественному планированию ИТ-ресурсов. Одновременно с этим БП управляет ожиданиями заказчика по ИТ-задачам внутри одного вида бизнеса, что способствует качественному принятию управленческих решений в развитии бизнеса.
Каким организациям необходим бизнес-партнер?
Верхнеуровнево можно выделить несколько триггеров, по которым имеет смысл задуматься о наращивании компетенции БП в организации:
1) Если в вашей организации ИТ-ресурсы не выделены в группы для реализации задач небольших бизнес-отделов, то велика вероятность, что ваша организация не в состоянии управлять ожиданиями бизнеса по ИТ-составляющей. В таких организациях ИТ-задачи большой, средней и маленькой трудоемкости стекаются в «трубу ИТ-ресурсов” и далее вряд ли ею системно управляют.
2) Если количество задач превышает ~200 штук на 1 вид бизнеса. Велика вероятность, что при таком объеме задач количество пересечений между отделами будет значительно, и скорее всего вам не раз уже приходилось точечно, через высшее руководство переприоритезировать задачи.
3) Если вы проводите комитеты по выделению ИТ-ресурсов. ИТ ресурсы всегда в недостатке в любой организации. Вопрос в том, хотите ли вы выстроить систему, в которой дефицит ИТ-ресурсов будет использоваться только для эффективных задач.
4) Если вы практикуете квотирование ИТ-ресурсов на виды бизнеса. Квотирование плохо тем, что для ИТ не видны реальные потребности бизнеса, соответственно в организации закрыты возможности для усиления ИТ-команд.
5) Если вас не устраивают показатели срока выпуска доработки. Не всегда очевидно, что имеются проблемы на стороне заказчика, в т. ч. срывы сроков. За показатели срока выпуска доработки всегда ответственны обе стороны (заказчик и ИТ).
Резюмируем: БП – это неудобный сотрудник для конечного заказчика и для ИТ-исполнителя одновременно, т. к. для заказчика появляется контролирующий инструмент эффективности его задач, а для ИТ-сотрудника появляется контролирующий инструмент сроков и очередности выполнения задач. Грамотный БП поможет организации добиться эффективности в процессе постановки и реализации задач с ИТ-составляющей.
По материалам PLUSworld.ru
Источник: plusworld.ru
