UPD: по результатам полученных комментариев решил вынести некоторые уточнения в начало статьи:

1. О способе изложения. Сложно предугадать как воспримят тот или иной контент разные люди. Не зная на сколько они погружены в терминологию и проблемы ИТ, я старался объяснить как можно понятнее. Это порождает большой объём. К тому же, указанное нельзя было оцифровать (предоставить показатели) по всему ИТ (по крайне мере в имеющееся время).

2. В письме топам, в кратком виде, указывались причины обращения и содержание приложенного документа. Всё остальное шло вложением.

3. Оценка трансформации, план, ресурсы и т.п. не делались, т.к. не была понятна позиция руководства по изложенному. К тому же, трансформация затронуло бы весь ИТ, а такое в одиночку просчитать и спланировать в крупных компаниях маловероятно. Если бы руководство выразило заинтересованность, то дальше пошли бы уточнения и согласования. 

4. Судить о предложенном составе отдела, без знания объёма работ поддерживаемых систем, и составов других отделов, затруднительно. Поэтому прошу к этому не придераться.

5. О связи пунктов. Я пытался представить их так:

   1. текущая ситуация в отделе

   2. выводы

   3. предложения по отделу

   4. предложения по всему ИТ

Поехали. Дано:

• большая производственная компания (>1тыс.чел.)

• за один год сменилось несколько руководителей ИТ

• в ИТ 100-300 чел

• автор - руководитель одного из отделов разработки, приглашённый чтобы наладить работу в одном из отделов разработки ПО (конкретики, что именно не устраивает руководство и какие показатели необходимо достичь, не выдвигалось).

Термины:

• ИС - информационная система

• МП - мобильное приложение

• БА - бизнес-аналитик

• РП - руководитель проекта

• ТЗ - техническое задание на разработку

• ДИТ - Дирекция по информационным технологиям

• БЕ - бизнес единица

• БП - бизнес-процессы

• ПО - программное обеспечение

• ИР - информационный ресурс (покупное/бесплатное ПО или разрабатываемое нами/подрядчиками)

1. Текущая ситуация в отделе

Компетенции отдела:

• аналитика (бизнес+системная) - 4 чел.

• разработка (бэк, фронт, вёрстка) - 2 чел.

Отдел отвечает за следующие группы ИС:

• web-аналитика (SEO/цели/счётчики/отчёты и т.п.) по любым сайтам и МП    

• направление-1 (МП-1 + МП-2 + сайт-1)

• направление-2 (МП-3 + сайт-2)

• направление-3 (сайты, 5 шт + МП-3)

• направление-4 (внутренние порталы, 2 шт)

• направление-5 (сайты, 30 шт)

• направление-6 (сайты, 10 шт)

• направление-7 (сайты, 2 шт)

1.1. Деятельности отдела

1. саппорт - работы по вводу контента, ответы на вопросы по работе систем

   1. кто участвует: сотрудник-1, сотрудник-2, сотрудник-3, сотрудник-4

   2. откуда приходят задачи: ИС-1, ИС-2, ИС-3, звонки, письма

   3. что делают: ввод контента, создание рекламных кампаний, ответ по телефону и email

2. аналитика - работы с ТЗ
   

   1. кто участвует: сотрудник-1, сотрудник-2, сотрудник-3, сотрудник-4

   2. откуда приходят задачи: ИС-1, ИС-2

   3. что делают: создание или согласование ТЗ, общение с подрядчиками

3. разработка
   

   1. кто участвует: сотрудник-5, сотрудник-6

   2. откуда приходят задачи: ИС-1, ИС-2, ИС-3

   3. что делают: реализуют вёрстку/код, анализ и оценка трудозатрат

   4. по выкладке кода
      

      1. гитлабом пользуются редко, в основном выкладывают из локальных репозиторий

      2. сайты обновляют через ftp

      3. порталы через ssh

4. тестирование
   

   1. кто участвует: сотрудник-1, сотрудник-2, сотрудник-4

   2. откуда приходят задачи: ИС-2

   3. что делают: тестирование, проверка данных в админках

5. администрирование
   

   1. кто участвует: сотрудник-4

   2. откуда приходят задачи: ИС-2, ИС-4, ИС-5, ИС-6, ИС-7, почта, телефон

   3. что делают: бюджетирование, закрывающие документы, согласования, общение с подрядчиками

Информации о работе отдела (команде, процессах, зоне ответственности, и т.п.) ранее нигде не отражалась.

1.2. Планирование

На данный момент во всём ИТ-департаменте нет единого места в котором можно увидеть планы/загрузку сотрудников отдела.

Задачи поступают из 5ти мест:

• ИС-1

• ИС-2

• ИС-3

• почта

• телефон

Нет сквозной системы приоритезации задач. Приоритет отдаётся запросам на обслуживание поступающим из ИС-1, т.к. по текущему каталогу сервисов, установлено время реакции на запросы. Данные запросы в 90% не являются бизнес критичными и могли бы обрабатываться на стороне 1-2 линий поддержки.

1.3. Аналитика

Из-за того, что в имеющихся учётных ИС нет возможности сделать сводку затраченного времени исполнителями по типам трудозатрат, то указанные ниже выводы делал на основании месячного наблюдения за деятельностью БА и фиксации данных на бумаге.

Выполняемые аналитиками работы и распределение затрачиваемого времени (в среднем):

• 25% времени - консультирование (пользователей, заказчиков, РП) ввод контента (на сайт или МП)

• 50% времени - тестирование (в том числе и того, что разработчики отдела не делали, например МП сделанного подрядчиком). Чаще всего аналитик не может один проверить кейс работы в котором участвуют несколько ИС, т.к. у него нет к ним доступа - это приводит к тому, что в тестировании участвуют несколько человек у которых есть доступы в нужную ИС, что растягивает время тестирования.

• 25% времени - работа с ТЗ (прямые обязанности)

Причины того, что аналитики занимаются своими прямыми обязанностями меньшую часть времени в следующем:

1. отсутствие приоритезации типов работ. По одному и тому же проекту, на одного и того же аналитика, одновременно могут приходить запросы и на консультирование, и на тестирование, и на работу с ТЗ.

2. отсутствие отдельных людей для тестирования, которые бы взяли на себя:
   

   1. тестирование

   2. написание инструкций, которые бы передавались первой линии для уменьшения работ по консультированию

   3. консультирование, в случае если первая линия не сможет ответить

3. тестирование и консультирование могут происходить без наличия в задач (например через телефонный звонок, который может растягиваться на 30-60 минут).

При наличии регламентов и положений описывающих зоны ответственности ДИТ и БЕ, со стороны БЕ присутствует:

• непонимание того, что требуется для них реализовать (как это должно работать) - не знают свои системы. Это приводит к увеличению сроков работы над проектами, т.к. аналитикам приходится “гадать”, что же надо БЕ, и по нескольку раз согласовывать требования.

• отсутствие возможности управления контентом в их системах - нет разграничения доступа ограничивающего права контент-менеджера. Это приводит к дополнительной загрузки аналитиков нецелевой работой.

1.4. Разработка

По всем web-проектам (лендингам/сайтам/порталам), находящимся под управлением отдела, отсутствует автоматизация работы с исходным кодом и его выкладки на сервера. Это влияет:

• на качество: выкладка кода происходит путём ручного копирования по ftp/ssh файлов на сервера - это чревато человеческими ошибками (забыл что либо скопировать в нужное место, или забыл изменить данные для дев/прод-версии)

• на скорость:
  

  • у разработчиков нет прав для установки на сервера нужных новых компонентов, от которых зависит работа нового кода - приходится ждать админов, когда они установят нужное

  • нет возможности автоматически тестировать подготовленные сборки кода для дев/прод-версий до их выкладки - узнать об ошибке мы сможем только выложив код на сервер и проверив его вручную

• на контроль: отсутствует использование докеризации - нет гарантии, что окружение кода на сервере, на 100% соответствует дев/локальному окружению - это усложняет и затягивает выявление ошибок.

Часть проектов находится у подрядчика - что не даёт нам:

• управлять кодом и серверами

• контролировать качество кода (из-за отсутствия у нас разработчиков со знаниями используемого подрядчиком стека технологий)

1.5. Выводы

Что необходимо сделать для улучшения результативности работы:

• планирования - использовать единую систему таск-трекинга. 
  

  • Что это даст компании - получим единое место планирования ресурсов и возможность автоматизировать процессы изменения статусов задач и публикации сайтов/приложений.

• аналитиков - необходимо определиться с основными обязанностями аналитиков - какую пользу для компании они должны приносить? Создавать ТЗ для новых разработок? Тестировать? Или консультировать? Так как это разные процессы, то улучшение работы по каждому из них, требует разных подходов (разные KPI). Не основные обязанности, передать другим людям (кому? об этом ниже). 
  

  • Что это даст компании - если аналитики будут заниматься только созданием ТЗ, то при отсутствии данных работ, они будут заняты следующим:
    

    • созданием описаний для первой линии, как отвечать на вопросы пользователей/бизнеса (неописанного очень много)

    • созданием ТЗ по исправлению накопленного технического долга. Подобных задач будет всё больше, как только на каждом уровне (консультации/тестирования/разработки) начнутся работы по выявлению их “узких мест”.

    • повышение удовлетворённости своей работой, как тем направлением, в каком они хотят расти профессионально 

• разработчиков - необходимо автоматизировать работу с кодом. 
  

  • Что это даст компании:
    

    • повышение качества результатов их работы за счёт ускорения рутинных операций и автоматизированному выявлению ошибок до того как они появятся на проде

    • повышение удовлетворённости своей работой, из-за расширения своих навыков 

    • повышение привлекательности нашей компании в глазах программистов

• сервисы - пересмотреть каталог сервисов и зоны ответственности, т.к.:
  

  • ответственный за сервис должен иметь возможность управлять сервисом. Например, отдел сейчас не имеет возможность управлять прод.версиями сайтов/порталов, т.к. доступ серверам есть только у администраторов - как тогда можно нести ответственность за сайт? Нужно разделять ответственность за разработку и работу ИС (об это будет описано ниже).

  • расширить описания требований к предоставлению сервисов, что в них входит, и SLA.

1.6. Варианты развития

Для того, чтобы отдел эффективно поддерживал работу текущих ИС в зоне его ответственности (указаны в начале отчёта) можно рассмотреть два варианта:

1. отказаться от своих разработчиков и передать всё на подряды - предлагаю его не рассматривать. В этом случае:
   

   1. аналитиков всё равно надо “прокачивать”, т.к. только они смогут сказать подрядчикам что им делать

   2. тестировщики, для тестирования кейсов, должны иметь доступы ко всем связанным ИС, чтобы не привлекать к работам нескольких человек, если это может сделать один

   3. в компании должны быть эксперты по всем технологиям используемым подрядчиками, чтобы проверять качество их кода. Иначе каждый новый подрядчик будет переписывать то что написали его предшественники, т.к. не сможет в том коде разобраться.

2. развивать свои отделы разработки (про идеальный вариант будет описано в следующем разделе):
   

   1. выделить для тестирования отдельных людей (не важно в каком отделе они будут находится). Это позволит:
      

      1. разгрузить аналитиков и ускорить их работы по анализу новых доработок 

      2. при создании ТЗ согласовывать с аналитиками кейсов тестирования (чтобы знать к чему готовится и подготавливать всё необходимое)

      3. создавать описания текущей функциональности и передавать её на 1-2 линии поддержки, что разгрузит тестировщиков для работ по автоматизации тестирования (для отлавливания ошибок на уровне разработчиков)

      4. нужно минимум два человека:
         

         1. сначала взять человека с большим опытом тестирования и организации данного процесса, чтобы он принял тестирование от аналитиков

         2. далее взять ему помощника, которому он передаст знания по ручному тестированию, а сам займётся автоматизацией тестирования.

   2. разработка (не важно в каком отделе они будут находится):
      

      1. разработчик на битрикс – есть вакансия. Зона ответственности:
         

         1. выполнение задач по доработка сайтов на битриксе

         2. перевод сайтов на битриксах к нам под управление

         3. оценка и приёмка работ от подрядчиков работ по битриксам

      2. разработчик на микросервисы – перевод текущих подсистем на более подходящий стек. Зона ответственности:
         

         1. выполнение задач по сервисам (API)

         2. стандартизация и унификация обмена между ИС через подключение их к работе с стандартизированным API

         3. разработка микросервисной архитектуры

      3. разработчик для МП (андроид/ios) – подходящего человека, пока, нет. Его зона ответственности:
         

         1. разработка МП-1,2,3

      4. постепенный переход к нам разработок МП-1 и 2

   3. DevOps-инженер – подходящего человека, пока, нет. Зона ответственности:
      

      1. автоматизация выкладки сайтов/портала/МП - поможет не просто быстрее выкладывать, а уменьшить вероятность человеческих ошибок, т.к. сейчас всё выкладывается через ftp, но никак не контролируется окружение остального, что есть на серверах

      2. разделение выкладки сайтов по отдельным виртуальным машинам (сейчас они сгруппированы и если упадёт ВМ, то целая группа сайтов будет недоступна)

      3. разработка DevOps-архитектуры

В итоге, чтобы улучшить качество работы отдела, предлагается расширить штат:

• прямо сейчас:
  

  • разработчик на битрикс

  • разработчик микросервисов

  • DevOps

  • ведущий тестировщик

• попозже:
  

  • помощник тестировщика

2. Видение идеальной ДИТ

Важно:

1. Цель предлагаемой трансформации - улучшение качества оказываемых бизнесу услуг со стороны ДИТ.

2. Названия предлагаемых уровней иерархий (служба, отдел, группа) не критичны и обсуждаемы.

3. Кто куда будет относиться в новой структуре, пока, опустим. Главное согласовать общее понимание к какому виду мы хотим привести ДИТ.

2.1. Текущие нежелательные явления

Описанное ниже сделано исходя из следующих предположений:

1. Нежелательными явлениями (НЯ) считается то, что мешает ДИТ максимально быстро реализовывать нововведения для бизнеса. Чем быстрее бизнес будет получать требуемое, тем выше конкурентоспособность компании в целом.

2. Бизнес (заказчик) знает что он хочет получить, т.е. как должна работать его ИС. Бизнес на своей стороне умеет анализировать все доступные варианты (консультируясь с ДИТ) и “приходить к ДИТ” с предельно ясными требованиями к нововведениям в ИС. Чтобы ДИТ не занимался “гаданием” что нужно бизнесу.

В текущий момент наблюдается следующие НЯ (список далеко не полный):

*ProductOwner - сотрудники со стороны бизнеса понимающие все БП происходящие в связанных ИС, с которыми работает бизнес, и принимающие решения что конкретно требуется от ДИТ, предварительно проанализировав все возможные варианты реализации. 

Понимаю, что всегда будут ограничения на варианты решения НЯ, но их надо решать, а не занимать позицию “так исторически сложилось”, “делать некому”, или “это не наша проблема”, что постоянно слышится от руководителей. Сотрудники перестают верить в компанию и становятся демотивированными.

Прочие НЯ, которые наблюдаются:

• неэффективная адаптации новых сотрудников - нет мест, где сотрудник получал бы актуальную информацию о работе его группы и всего что с ней связано (нет отбординга)

• сложный процесс получения доступов/согласований - применяется принцип “проще запретить чем грамотно настроить”

• скудность используемых технологий - всё крутится вокруг 1С. Не используется поиск вариантов применения современных технологий для решения имеющихся проблем или замены неэффективных решений. Это позволит улучшить привлекательности компании для айтишников за счёт широкого круга проектов/технологий.

• неэффективный таск-трекер (1С) - задачи аналитиков/разработчиков/тестировщиков должны быть связаны с системой доставки кода на продуктовые площадки. Сейчас таких систем в компании две:
  

  • Jira + Confluence 

  • GitLab 

• при обновлении подсистем необходимо тестирование сайтов/МП которые с ними связаны - о том что потребуется такое тестирование со стороны отдела не всегда предупреждают.

• несогласованность зон ответственности
  

  • с департаментом-1 по SEO и сквозной аналитике

  • с департаментом-2 по их сайтам

2.2. Предложение по трансформации

По своему опыту скажу, что организуя в одном отделе работу поддержки, эксплуатации и разработки – добиться предоставления быстрого и качественного результата по всем трём направлениям не удастся, т.к. в приоритете всегда будет создание нового, нежели поддержка текущего.

Поэтому следует разделять понятие «поддержки» в зависимости от того можем ли мы дорабатывать софт/технику не влезая в код/устройство или не можем. И возможные показатели KPI у данных направлений работ разные.

Любая деятельность ДИТ должна быть связана с деятельностью компании и её высокоуровневыми целями. 

Т.к. мне не удалось найти официальных “бумаг” описывающих связь деятельностей и целей компании с деятельностью ДИТ (и на словах тоже никто не может объяснить), то описанное ниже делал на основании своих предположений о “правильности”.

2.2.1. Что нужно компании от ДИТ

Для начала, выделим направления деятельности компании (возможно список не полный):

1. направление-1
   

   • поднаправление-1.1

   • поднаправление-1.2

   • поднаправление-1.3

   • поднаправление-1.4

2. направление-2
   

   • поднаправление-2.1

   • поднаправление-2.2

3. направление-3
   

   • поднаправление-3.1

   • поднаправление-3.2

4. направление-4

Для каждого направления деятельности компании нужно обеспечить:

1. предоставление мест для работы сотрудников

2. организацию совместной работы сотрудников - инфраструктуру (сервера/ИС)

3. ввод “нововведений” (т.к. всё меняется)

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

2.2.2. Разделение на типы оказываемых сервисов

На основании данного разделения выделяются следующие типы (или виды) сервисов, которые может оказывать ДИТ:

1. Тип “Рабочее место” - организация места работы сотрудника. В него входит:
   

   1. Поддержка (ответы на вопросы) - цель сервиса: максимально быстро решить вопрос сотрудника связанные с его рабочим местом (далее надо будет конкретизировать список вопросов для всех типов и поддерживать их актуальность). 

   2. Эксплуатация - установка/удаление/починка (техника/доступы/ПО) - цель сервиса: максимально быстро предоставить новое рабочее место, удалить ненужное, или починить текущее.

2. Тип “Инфраструктура” - организация коллективной работы сотрудников (корпоративные сервера/ПО). В него входит:
   

   1. Поддержка - цель сервиса: максимально быстро решать вопросы сотрудников по использованию имеющихся в компании систем, в рамках доступного данными системами в текущий момент (например, вносить изменения через админку, без привлечения разработчика):
      

      1. серверов

      2. сервисов (API)

      3. порталов

      4. сайтов

      5. систем аналитики/проектирования/…

   2. Эксплуатация - установка/удаление/починка - цель сервиса: максимально быстро предоставить новый корпоративный сервис (сервер/сайт/портал/API), удалить ненужный или восстановить работу в случае поломки. Начальную разработку новых сервисов будет делаться в рамках типа сервиса “Нововведение”.

3. Тип “Инновации” (либо другой, более подходящий термин) - цель сервиса: максимально быстро разработать новое (техника/ПО), чего ещё небыло в рамках имеющихся систем в компании (добавление нового на сайты/API/инфраструктуру/железо) и передать на установку и поддержку в “эксплуатацию”. 

2.2.3. Разделение на службы

Для эффективной обработки указанных выше типов сервисов, необходимо разделить их выполнение по отдельным службам (группам/отделам/департаментам):

• служба поддержки - для решения всех запросов с подтипом “Поддержка” (для типов сервисов “Рабочее место” и “Инфраструктура”). Сотрудники данной службы могут работать удалённо и распределённо по стране, отвечая на вопросы по телефону или электронные средства связи.

• служба эксплуатации - для решения всех запросов с подтипом “Эксплуатация” (для типов сервисов “Рабочее место” и “Инфраструктура”). Отчасти сотрудники данной службы могут работать удалённо, отчасти находиться на объектах компании.

• служба инноваций - для решения всех запросов с типом “Инновации”.

Суть указанного разделения по службам в следующем:

• служба поддержки – работает по инструкциям и по документации (тут нужны будут технические писатели, которые будут консультироваться у эксплуатации и инновациям при поддержании инструкций в актуальном виде). Если документов нет, вопросы эскалируют в службу эксплуатации. В данной службе будут аккумулироваться все знания о процессах и системах компании.

• служба эксплуатации – в ней находятся люди знающие как работает техника/ИС (в том числе эксперты). У них есть доступы к изменениям настроек. Если ситуация с запросом от службы поддержки может повториться, то они порождают инструкцию и передают её в службу поддержки. Если они не могут решить запрос и породить инструкцию, то эскалирует в службу разработки.

• служба инноваций – в ней находятся люди которые могут менять реализацию техники/ИС под поступающие запросы. Результаты, вместе с документацией, передают в службу эксплуатации, которая приняв в работу ИС, передаёт поддержке документацию.

Такое разделение служб позволит “выращивать” грамотных сотрудников, проходя путь через поддержку, эксплуатацию и инновации (если они захотят расти в данном направлении). 

Если рассматривать идеальный вариант, то служба инноваций нужна только на этапе трансформаций. Т.е. когда нужно обновить внутреннюю ИТ-инфраструктуру или разработать новый ИС. После этого, вроде как, служба инноваций не нужна, т.к. всё перекладывается на службы поддержки и эксплуатации. Но т.к. всегда происходят какие либо изменения в бизнес-процессах, и невозможно заранее предусмотреть и реализовать возможности изменять то что потребуется делать через настройки (т.е. только за счёт использования службы эксплуатации), поэтому потребность в службе инноваций будет всегда. Кто будет делать разработку, своими силами или на подряде, вопрос открытый, но эксперты в службе инноваций нужны компании, т.к. от них будет зависеть постановка подрядчикам заданий, с учётом нашей архитектуры и приём результатов.

Возвращаясь к описанию служб и что они будут делать:

• служба поддержки - точка входа любых вопросов от всех подразделений, цели которой:
  

  • максимально быстро решать вопросы по инструкциям или эскалировать вопросы службе эксплуатации

  • сокращать издержки по своей деятельности

• служба эксплуатации – цели:
  

  • управлять (контроль и мониторинг) техникой и ИР или эскалировать вопросы службе инноваций

  • оптимизировать работу подконтрольных систем (надо не просто отвечать за работу систем, но и проводить работы по их улучшению). Если выясняется что для улучшения потребуется доработка, то создаётся ТЗ в службу инноваций.

  • передавать описания ввода нового (техники/ПО) в службу поддержки

  • сокращать издержки по своей деятельности

• служба инноваций – цели:
  

  • разработка нового (софта/инфраструктуры/оборудования)

  • передавать результаты и описания нового в службу эксплуатации

  • сокращать издержки по своей деятельности

Важно:

1. явное указание в целях сокращение издержек - позволит службам обосновывать причины оптимизации их работы, которые могут касаться изменений в лучшую сторону бизнес-процессов связанных подразделений, и не даст ответственным за ИС забывать работать над улучшениям того, что в зоне их ответственности.

2. каждое эскалирование проблемы, должно рассматриваться для того, чтобы улучшить работу всей цепочки решения запросов. Стремиться к тому, чтобы запрос приходил сразу конечному исполнителю с максимально полной информацией для решения запроса.

С одной стороны, “все” указанные работы у нас так, или иначе, “делаются”. Но к результатам этого “делания” всегда есть вопросы/замечания/претензии. Причины недовольства - в отсутствии явного разделения зон ответственности. Описанная выше структура решает эту проблему.

2.2.4. Составы служб

Относительно возможного состава и структуры служб:

• служба поддержки
  

  • начальник – его цели:
    

    • сокращать количество обращения с вопросами от бизнес-единиц (БЕ)

    • уменьшать время закрытия вопросов от БЕ

    • оптимизировать расходы на службу

  • группа 1й линии – их цели:
    

    • выполнение полученных запросов или делегирование в службу эксплуатации

• служба эксплуатации
  

  • начальник – его цели:
    

    • достижение отказоустойчивой работы техники/ИР в режиме 24/7

    • сокращать количество обращения с вопросами от БЕ

    • уменьшать время закрытия вопросов от БЕ

    • оптимизировать расходы на службу

  • разделения по типам эксплуатации (железо/устанавливаемый софт/сайты/продвижение сайтов) – тут надо будет подумать. В службе должны быть люди знающие как настраивать обслуживаемое железо/софт/сайты. Но изменения (тут будет важно определить и закрепить понятие, что же подразумевается по этим термином, т.к. для меня «перекраска кнопочки в другой цвет» - это уже изменение) проводить через службу инноваций, если это нельзя сделать через админку системы.
    

    • здесь должны быть очень грамотные специалисты (сейчас это эксперты у нас) по всем видам софта принятого в эксплуатацию (1С, системное администрирование, сайты, ПО)

    • продвижение сайтов указал в эксплуатации, т.к. данная работа чаще всего связана с настройками вносимыми через админку систем. Но если что то нельзя будет сделать через админку, то будет эскалация на уровень инноваций, для добавления требуемой функциональности.

  • группы 2й линии - решают вопросы настроек, доступов, тюнинга производительности ИС:
    

    • группа 1С (всё что касается продуктов 1С)

    • группа сервисов (API/взаимодействие между ИС)

    • группа web (порталы/сайты/лендинги)

    • SEO-продвижение

    • их цели - выполнение полученных запросов или делегирование в службу инноваций

• служба инноваций
  

  • начальник – его цели:
    

    • уменьшать время закрытия вопросов от БЕ на изменения

    • оптимизировать расходы на службу

  • группа архитектуры (всё что касается вопросов архитектуры всех ИС в компании)

  • группа 1С (всё что касается продуктов 1С)

  • группа девопс (всё что касается автоматизирования запуска нового софта в зонах D/Q/P)

  • группа аналитики (по всем подсистемам) - в идеале вынести бизнес-анализ на уровень бизнеса, по причинам указанных выше.

  • группа сервисов (API/взаимодействие между ИС)

  • группа web (порталы/сайты/лендинги)

  • группа тестирования (всех подсистем)

  • группа дизайна

  • группа мобильной разработки

  • цели групп - выполнение полученных запросов или обоснование их нецелесообразности 

Необходимость деления на отделы внутри служб, пока мне не понятна. Тут надо будет проработать вместе с начальниками служб.

Важно, чтобы любую доработку или изменения в использовании софта (как например, переезд сайта с одного сервера на другой, смена системы сервис-деска или т.п.) проводить через службу инноваций, т.к. если переездом будут заняты сотрудники группы эксплуатации, то это скажется на их показателях обработки запросов.

2.2.5. Проектный офис

Проектный офис должен находится в непосредственном подчинении высшего руководства и работать по его требованиям в интересах компании в целом. Другие подразделения компании хотя и не находятся в подчинении офиса, обязаны следовать его указаниям в части стандарта управления проектами компании и следовать его рекомендациям по управлению конкретными проектами.

2.2.6. Контроль 

Чтобы контролировать работу каждого ИР на всех стадиях, необходимо выделение следующих ответственных:

1. Владелец ИР – Лицо принимающее решение (ЛПР), когда указанные ниже не готовы брать на себя ответственность. У нас он есть, так и называется “Владелец”, но он отвечает за данные внутри системы, а не за её работу.

2. Контроль работы ИР – Отвечающий за доступность ресурса в сети (локальной или интернет)

3. Поддержка ИР – Отвечающий за настройку и обучение пользователей ресурса

4. Разработка ИР – Отвечающий за добавления изменений и исправление багов

Это всё могут быть разные люди.

Чтобы высшее руководство, в любой момент, имело понимание как идёт трансформация, а не смотрела в xls-таблички (которые невозможно как проверить), нужно чтобы показатели любого сотрудника были связаны с глобальными целями уровня БЕ. Например, через использование системы OKR.

Прямая поддержка руководства критична для правильной работы системы целеполагания. Если высшее руководство не понимает, не вовлечено или не использует систему, то инициатива быстро сходит на нет.

Поэтому для успеха критично иметь человека или команду, отвечающего за процесс трансформации на постоянной основе.

Все понимают, что для улучшения текущей ситуации нужны преобразования. Чтобы не заниматься пустым доказательством всех текущих проблем (собирать статистику и т.п.), предлагается:

1. согласовать и принять стратегию трансформации

2. согласовать общий план преобразования (корректируя его по ходу движения к цели)

3. и начать двигаться по тему, а не пытаться менять каждый на своём уровне, т.к. результаты несогласованных действий потребуют переделки всего заново. 

Резюме

В итоге, топ-менеджмент компаний оставили предложения без ответа.

Что в итоге я хочу добиться данным постом:

1. Поделиться своим опытом и узнать было ли у кого-либо подобное и как решили?

2. Если вы топ-менеджер в компании, то какая бы была ваша реакция на получение подобного письма от подчинённого, располагаемого где-то внизу по иерархической лестнице?