4 июня 2019 года издательство «Открытые системы» проведет в Москве IT Management Forum — ITMF 2019, единственный на российском рынке форум, где обсуждаются все главные темы управления ИТ. Форум организуется уже в 16-й раз.

ITMF 2019 — главное событие года для профессионалов в области управления ИТ —пройдет под девизом «Выбираем правильный ИТ-курс в океане цифровизации». Участников форума ждут насыщенные треки докладов, обсуждение самых актуальных тем в открытых дискуссиях и мастер-классы мировых гуру и российских экспертов, непосредственно вовлеченных в глобальный процесс развития стандартов и методов управления.

«Сфера управления ИТ постоянно совершенствуется, обогащаясь новыми методиками, инструментами, опытом, и наш форум всегда отражает самые важные этапы этого развития, — отмечает Наталья Дубова, программный директор ITMF 2019. — На ITMF 2019 будут представлены ключевые тенденции, стратегические перспективы и примеры лучшего практического опыта управления ИТ в мире и России в контексте цифровой трансформации бизнеса».

Среди основных тем ITMF 2019:

• ИТ и бизнес: пути к эффективному партнерству
• Стратегические модели управления в цифровом бизнесе
• Сервис как ценность цифровой экономики: от управления ИТ-сервисами к управлению бизнес-сервисами
• Управление проектами и продуктами цифрового предприятия
• Agile, DevOps, ITSM: синхронизация для успеха цифровой трансформации
• Управление рисками цифрового бизнеса

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

В числе спикеров ITMF 2019:

• Маурисио Корона, директор по трансформации, Service Desk Institute
• Максим Григорьев, управляющий партнер, Gartner
• Роман Журавлев, менеджер по развитию ITSM-портфеля, Axelos
• Ольга Павленко, советник по развитию цифровых услуг, Благотворительный фонд «Даунсайд Ап»
• Андрей Алмазов, директор центра развития комплексных проектов НТИ, АО «РВК»
• Павел Алферов, профессор бизнес-практики, Московская школа управления СКОЛКОВО

О классических методах управления проектами и управлении в стиле agile расскажут в своих выступлениях профессионалы проектного и продуктового менеджмента из компаний «Русагро», «Ростелеком», МТС, X5 Retail Group, «СИБУР».

Опытом трансформации управления сервисами в цифровую эру на тематической сессии ITMF 2019 поделятся менеджеры ДИТ Москвы, ИТСК («Газпром нефть»), «Ингосстраха», ГБУ «Инфогород».

1.  
2.  
3.  
4.  
5.  
6.  

Пред.След.

Только недавно увидела свет первая публикация ITIL 4 — масштабного обновления ITIL, первого за 12 лет. Профессионалы сервис-менеджмента во всем мире обмениваются впечатлениями, отмечая достоинства и недостатки новой версии. Участникам форума предоставится шанс присоединиться к такому обсуждению, поделиться своим мнением и получить ответы на вопросы непосредственно от cоздателей ITIL 4. Программа ITMF 2019 включает пленарные выступления и круглый стол с участием архитекторов эпохального обновления ITIL — Маурисио Короны и Романа Журавлева.

Цифровизация сопровождается неопределенностью и несет с собой риски, которыми нужно управлять. Дискуссию «РискОвый менеджмент: управление операционными рисками в системе корпоративного управления» будет модерировать Антон Боганов, председатель itSMF России, директор по развитию Axios Systems.

Еще один круглый стол соберет недавно созданное сообщество «IT для людей», где обсудят вопросы клиентоориентированности ИТ-службы внутри компании. Правильная стратегия развития службы Service Desk для достижения максимально качественного клиентского опыта — тема мастер-класса международного эксперта Маурисио Короны.

Евгений Шилов и Олег Скрынник из компании Cleverics проведут на ITMF 2019 мастер-класс по оптимизации процесса поддержки для применения алгоритмов машинного обучения. Если вопросы настройки алгоритмов подробно рассматриваются во множестве материалов, то оптимизация самих процессов для использования таких алгоритмов остается незаслуженно забытой. Специалисты Cleverics постараются восполнить этот пробел.

Ожидается, что в этом году авторитетнейшая площадка ITMF соберет для делового и дружеского общения более 300 профессионалов в управлении ИТ и их бизнес-партнеров, представляющих разные отрасли и сферы деятельности. Ведущие ИТ-компании познакомят их со своими инновационными решениями в области управления ИТ и поделятся опытом их применения.

Генеральный партнер форума - Axios Systems. Партнерами выступили: Naumen, Роспартнер, OMNINET, Cleverics, Leaseweb, Softline, ICL Services. Партнер выставки - ITAM2.ru.

«Почему цифровая трансформация дается компаниям так тяжело? Проблема в том, что процессы разработки ПО организованы кое-как», — заявил Олег Скрынник, управляющий партнер Cleverics, в рамках практической конференции CleverDAY. Дело в том, что именно программные решения находятся в основе всех современных тенденций. Более того, сейчас компании дифференцируются с помощью ПО, пытаются строить с их помощью конкурентные преимущества – именно там фиксируются процессы, взаимодействия с партнерами и клиентами. И сейчас все существующие недостатки разработке систем начинают очень сильно отражаться на возможностях развития компаний.

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

«Надо наводить порядок – все будут этому рады. Хотя и не сразу покажут это», — отметил Скрынник.

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

Следующая проблема – неоднородность технических практик. Необходимо провести их ревизию, выявить лидеров и отстающих, а также очаги современных подходов. Учить и разъяснять, искать примеры внутри. Так устраняется неоднородность, и подразделение начинает двигаться вперед.

Отдельный вопрос, актуальный для многих, — где брать наставников? Agile-команды сами собой не заработают, а коучей в компаниях нет. Самоорганизация возможна и должна поощряться, но на нее не стоит рассчитывать на ранних стадиях формирования команд. Рынок внешнего труда тоже не поможет – он перегрет и пуст, надо искать перспективных кандидатов внутри, создавать свои школы. Большая иллюзия, что на каждую команду удастся выделить по скрам-мастеру, — это дорого и нереально. Им придется совмещать работу в нескольких командах.

Еще один бич большинства компаний – отсутствие измерений. Как правило, в разработке ПО объективно никто ничего не знает: есть одни ощущения, планы и сорванные сроки. В лучшем случае для отчетности используются стандартные диаграммы из Jira. Здесь можно посоветовать использовать визуализацию: рисовать поток создания ценности, ставить отметки по времени, и не бояться сравнивать команды между собой.

Наконец, многих губит чрезмерная увлеченность проектным управлением. «Мы слишком любим проекты. Придется определиться: либо управлять проектом, либо управлять продуктом», — подчеркнул Скрынник. Ограниченные временными и функциональными рамками проекты – это вовсе не то, что нужно большинству компаний в нынешних условиях, когда речь идет о поддержке жизненного цикла бизнес-решений. Кроме того, когда нужна скорость, рекомендации PMBoK и PRINCE2 не помогут.

Цифровая трансформация дается тяжело, потому что ей не на что опереться. Надо учиться разрабатывать ПО быстро и с очевидной ценностью для бизнеса.

Правда ли, что agile и проекты в госорганизациях – «вещи несовместные»? Доклады сессии «Опыт» практической конференции «Agile.DevOps.ITSM 2018», проведенной издательством «Открытые системы», демонстрировали, что это не так.

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

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

Тем не менее в реальной практике элементы agile, необходимые для успешного и оперативного завершения проекта, удается интегрировать с этими, казалось бы, «железобетонными» принципами госИТ. Добриднюк поделился некоторыми рецептами на примере запуска в июле этого года «Перспективной платежной системы России», инициированного Банком России, реализованного государственным «МСП банком» в партнерстве с компанией «Диасофт» и задействовавшего все банки страны.

В частности, оказалось, что современные чиновники и даже топ-менеджеры госкорпораций, как правило, не избегают присутствия в соцсетях, более того, дорожат своей репутацией там, и этот канал можно использовать как действенный инструмент оперативной связи. Для доходчивого описания заказчику бизнес-архитектуры решения применили удобные средства визуализации в стиле «комиксов», что позволило наглядно объяснить основные идеи проекта прежде чем они были формализованы в строгом ТЗ. Взаимной вовлеченности заказчика и исполнителя способствовал «перехват ответственности»: участники команды разработки брали на себя часть функций заказчика из госорганизации, на которые у последнего не хватало компетенций, и, наоборот, давали «порулить» заказчику в процессе выработки деталей технического решения и управления разработчиками, если это помогало лучше донести входные требования.

Сергей Добриднюк рассказал, что мешает проникновению гибких подходов в госпроекты и как их тем не менее можно там использовать

Департамент информационных технологий Москвы не может не быть примером показательного исключения из правил работы ИТ в госорганах, иначе столица не выбилась бы в лидеры мировых рейтингов цифровых городов. Михаил Потоцкий, руководитель продукта Service Manager в ДИТ, рассказал о придуманной им agile-схеме реализации запросов на изменения платформы, на которой базируется техподдержка всех информационных систем «электронной Москвы». «Мы просто обязаны показывать пример качественной и при этом гибкой работы другим продуктам, которые использует город», — отметил Потоцкий.

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

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

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

«Это было не упражнением по изменению технологий тестирования, но трансформацией подхода к работе, синтезировавшей несколько методологий управления. Из принципов Lean была взята нацеленность на результат – ускорение обработки запросов – и отсечение всего лишнего, что достижению этого результата мешает. Из ITSM – организация процессов, из Agile – коллективные методы работы. И очень важна корпоративная культура – проведение этих идей в жизнь стало плодом совместной работы команды, а не бездумным исполнением воли руководителя», – рассказал Потоцкий.

Еще в 2014 году инвестуионная компания Thoma Bravo в рамках 2,5-миллиардной сделки вернула разработчика программного обеспечения Compuware, завоевавшего свою славу еще во времена мейнфреймов, с биржи в частное владение.

На должность генерального директора Compuware был приглашен Кристофер О'Малли, решивший осуществить ускоренный переход от «водопадной» модели к DevOps и Agile-разработке, охватив при этом практически все аспекты бизнеса, начиная от организации групп разработки и эксплуатации и заканчивая маркетинговыми и финансовыми подразделениями, а также бухучетом.

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

«Мы, если хотите, переживаем сейчас второе рождение, – заявил вице-президент компании по продуктам Дэвид Риццо. – В Compuware стремятся предлагать инновационные решения для мэйнфреймов, а это требует перехода от нашей традиционной водопадной модели к DevOps и гибким методикам организации бизнес-процессов».

Кристофер О'Малли решил осуществить ускоренный переход к DevOps, охватив при этом практически все аспекты бизнеса

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

«У нас был очень опытный персонал и укоренившиеся процессы, но нам требовалась трансформация, позволяющая энергично продвигаться вперед, – подчеркнул Риццо. – И мы осознанно приступили к этому, прекрасно понимая, что столкнемся с проблемами, поскольку масштабные изменения всегда влекут за собой определенные сложности».

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

«Наша цель заключалась в том, что сохранить специалистов и предоставить им возможность работать новым, иным способом, используя преимущества гибкой разработки и DevOps, – пояснил Риццо. – Конечно, главные трудности связаны с людьми – мы должны содействовать их развитию, предоставлять официальное обучение, приглашать преподавателей, давать инструменты, которые им нужны для успеха. На начальном этапе удовлетворению необходимых потребностей уделялось особое внимание. Мы хотели убедиться в том, что у нас формируется правильная культура, правильная среда и есть правильные инструменты. Реформы коснулись не только процесса разработки продуктов. Они затронули всю организацию, через это должен был пройти каждый – продукты требовали кооперации с юридическим отделом, с финансовым отделом, с договорами, продажами, словом, со всеми нашими сотрудниками».

Помимо всего прочего требовалось определить конкретные сроки, и в результате было принято решение о том, что с ноября 2014 года вся компания переходит на DevOps. «Нам понравилась идея сжечь за собой мосты и просто двигаться вперед, – вспоминал Риццо. – Теперь, по прошествии времени, мы видим, что добились значительных успехов, поскольку выбрали правильный путь».

Новое руководство поощряло чтение сотрудниками романа «Проект 'Феникс'» (бестселлер Джина Кима, Кевина Бера и Джорджа Спаффорда «Проект 'Феникс'. Роман о том, как DevOps меняет бизнес к лучшему». — Прим. ред.) и его коллективное обсуждение, в котором принимали участие представители разных подразделений. Таким образом, представители кадровой службы, финансового отдела и разработчики активно общались друг с другом. Они видели, как все это отражается на их повседневной жизни и деятельности их групп, а не только на разработке. Таким образом, процесс перехода получил полную поддержку и понимание.

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

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

В итоге выбор инструментария привел к тому, что Compuware купила разработавшего его компанию, и теперь система ISPW развивается под крылом Compuware.

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

«И вот тогда мы впервые оглянулись назад и признали, что это действительно работает, – отметил Риццо. – Новая методология раскрыла наши творческие и инновационные способности, позволив нам действовать быстрее, чем раньше, особенно в сфере, традиционной для мира мейнфреймов».

Традиционные ключевые показатели эффективности оценивают число дефектов, о которых сообщают клиенты, и начиная с 2014 года количество этих дефектов в Compuware неуклонно снижается. Кроме того, компании удалось успешно вписаться в новый 90-дневный цикл разработки продуктов, на который она и ориентировалась, приступая к трансформации.

Сергей Архипенков, директор департамента комплексных архитектурных решений RedSys

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

Корпоративные системы нового поколения (КИС 2.0) должны обеспечивать комплексную автоматизацию основной, хозяйственной и управленческой деятельности, управление материальными активами и персоналом, взаимодействие с клиентами и партнерами; поддержку тысяч подразделений и филиалов, распределенных по всей территории Российской Федерации и за ее пределами; работу сотен тысяч пользователей, десятки тысяч из которых используют КИС одновременно; тысячи транзакций ежесекундно; сотни терабайт, хранимых и обрабатываемых данных с ежегодным приростом.

Cергей Архипенко: «Наиболее эффективный процесс по проектированию и созданию КИС 2.0 должен основываться на гибком итеративном и инкрементальном подходе»

Компания RedSys специализируется на создании КИС нового поколения, которые можно назвать «системами систем» (Systems of Systems). Заказная разработка таких КИС – это всегда сложный и масштабный процесс, включающий в себя миллионы человеко-часов работы и десятки миллионов строк исходного кода.

Немного истории: «наследие девяностых»

Первые КИС появились еще в середине 90-х годов прошлого столетия, и в основе их лежали информационные и коммуникационные технологии, программное и аппаратное обеспечение которые были актуальны в то время. В те годы заказчики, как правило, не задумывались ни о концептуальном проектировании бизнес-процессов, ни о комплексной автоматизации в целом, а решали локальные задачи. Впоследствии многим из них пришлось столкнуться с последствиями «лоскутной» или «островной» автоматизации. За прошедшие десятилетия на предприятиях и в организациях накопилось множество не только физически, но и технологически устаревших программно-аппаратных комплексов, построенных, как правило, по клиент-серверной либо по монолитной архитектуре.

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

КИС нового поколения как «система систем»

Мир изменился, и работать на устаревших технологиях сегодня уже просто невозможно. За прошедшие десятилетия в ИТ произошли существенные сдвиги, которые, несомненно, не могли не отразиться на процессах разработки корпоративных информационных систем. Так, существенно снизилась стоимость единицы пропускной способности каналов связи, при этом сама пропускная способность растет в среднем на 50 процентов ежегодно. Облачные технологии сегодня помогают организациям унифицировать инфраструктурные стандарты и предоставить приложениям необходимую им ИТ-инфраструктуру в качестве сервиса по модели IaaS. Облака дают возможность максимально быстро масштабировать и динамически менять вычислительные ресурсы, выделяемые приложениям, что позволяет ИТ-департаментам идти на самые смелые эксперименты, пробовать любые инновационные решения без ущерба для бюджета компании. Наконец, и сама техническая архитектура становится проще и понятнее, благодаря использованию унифицированных компонентов. Немало изменений произошло за эти годы и в сегменте аппаратного обеспечения. Умные устройства на базе Интернета вещей, высокоскоростные технологии передачи данных, спутниковый интернет, телематические стандарты, ГЛОНАСС/GPS, видеонаблюдение с видеоаналитикой сегодня стали повседневной реальностью. Программное обеспечение на базе открытого исходного кода, которое в 90-е годы считалось уделом небольшого сообщества энтузиастов, сегодня развивается и поддерживается крупными ИТ-корпорациями и используется как промышленный стандарт, поскольку его качество уже давно не уступает коммерческим аналогам. Достаточно напомнить об исследовании тестинговой компании Coverity, проведенном совместно с американским Отделом национальной безопасности. Его результаты показали, что открытый исходный код не уступает по качеству проприетарному. Наиболее качественные проекты (Linux 2.6, PHP 5.3 и PostgreSQL 9.1), имеют 0,62, 0,20, и 0,21 дефектов на тысячу строк кода соответственно.

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

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

Agile по ГОСТ и системы нового поколения

Наиболее эффективный процесс по проектированию и созданию КИС 2.0 должен основываться на гибком итеративном и инкрементальном подходе. Фазы анализа, проектирования, разработки и внедрения будут циклически повторяться, а результатом каждого цикла станет добавление в находящиеся в постоянной эксплуатации системы новых востребованным пользователями функций, а также повышение качества работы. Сколько времени может занимать каждая итерация? Это зависит от сложности задач, но в среднем этот срок обычно составляет от одного до нескольких месяцев.

Не противоречит ли такой подход ГОСТам, которые, как считается, предусматривают исключительно «водопадную» модель разработки? Нет — если вы разрабатываете Техническое задание согласно ГОСТ 34.602-89, вам необходимо максимально подробно прописать нефункциональные требования к КИС, потому что именно они определяют архитектуру системы. Что касается функциональных требований, то и они при этом описываются на достаточно высоком уровне. На следующем этапе проектируется архитектура, которая описывается в Техническом проекте по ГОСТ 34.201-89 и РД 50-34.698-90. Параллельно запускается итеративная и инкрементальная разработка. На каждой итерации уточняются функциональные требования в виде сценариев использования в документах «Проектные решения» по ГОСТ 34.003-90, которые по мере готовности утверждает заказчик, а затем они прикладываются к Техническому проекту. Так реализуется гибкий, итеративный и инкрементальный подход.

Корпоративные информационные системы нового поколения, разработанные по современным стандартам, с применением новейших информационных и коммуникационных технологий, и в соответствии с комплексным подходом, дает заказчику целый ряд преимуществ. Организация получает единое информационное пространство, позволяющее решать задачи и обеспечивающее доступ к данным в режиме реального времени. Инфраструктура становится гибкой и масштабируемой, а это означает, что на ближайшие 15-20 лет вопросы интеграции имеющихся и создания новых информационных систем будут решаться быстро и безболезненно. Повысится уровень автоматизации бизнес-процессов и государственных функций, а взаимодействие с партнерами, клиентами и контрагентами станет легче и проще, как и административные и технологические процедуры. Современные инструменты мониторинга работы систем и оборудования позволят не только удаленно управлять инфраструктурой, но и прогнозировать инциденты, своевременно предупреждая их. Благодаря единым стандартам, регламентам и инструментам, жизненный цикл КИС станет более прозрачным и предсказуемым. Наконец, за счет энергоэффективных технологий и применения открытого ПО снизится общая стоимость владения КИС и затраты на обслуживающий персонал.

Критерий истины — проекты

В качестве практического примера, расскажем о двух проектах по построению КИС, реализованных специалистами компании RedSys. Первый — в Пенсионном фонде Российской Федерации, где был осуществлен проект по внедрению Автоматизированной информационной системы нового поколения (АИС ПФР-2) в ходе которого была разработана и создана новая инфраструктура, которая поддерживает выполнение всех функций на любом уровне.

Пенсионный фонд России — одна из крупнейших федеральных структур (более 140 тыс. сотрудников, 2,8 тыс. точек присутствия во всех субъектах РФ, многие из 25 подсистем ее КИС по сложности и масштабу соответствуют «целым» информационным системам иных федеральных ведомств.

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

Благодаря масштабируемости новой КИС, когда к России были присоединены Крым и Севастополь, Пенсионный фонд смог развернуть в новых регионах типовые комплексы по предоставлению пенсионных услуг в течение двух недель.

Второй проект был осуществлен в Ростехнадзоре, в котором, в ходе модернизации ИКТ-инфраструктуры, разрозненные системы сменила комплексная система информатизации (КСИ), объединяющая около двух десятков абсолютно разных подсистем с разным количеством пользователей. Часть этих систем отвечала за автоматизацию основной деятельности ведомства, часть – за автоматизацию управленческой. При этом все системы интегрированы между собой. В целом в ней работает около 2 тысяч пользователей из 150 тысяч поднадзорных организаций. После внедрения КСИ в ведомстве появилась единая база организаций и единые методологические принципы ведения реестров, автоматизации госуслуг, единая база доступа к спецификациям, протоколам и техническим заданиям.

Цифровая экономика усилила один из ключевых принципов экономики традиционной: необходимо как можно быстрее выводить на рынок новые продукты и услуги, причем их качество должно быть достаточно высоким. Методика DevOps помогает разработчикам за меньшее время создавать и передавать в эксплуатацию цифровые продукты и сервисы, добиваясь при этом необходимого уровня качества. Какова нынешняя ситуация с DevOps, в каком ракурсе ее следует рассматривать и чего можно ждать от этой методики, рассказывает Марк Смолли, консультант компании Smalley.IT в области управления ИТ, всемирный посол фонда ASL BiSL Foundation. Смолли выступил с ключевым докладом на юбилейном, пятнадцатом форуме ITMF 2018 для профессионалов в области управления ИТ, организованном издательством «Открытые системы».

- С чем связана нынешняя шумиха вокруг DevOps?

Эта методика зародилась в 2008-2009 годах в Бельгии: эксперты попытались применить гибкие (agile) методики разработки для управления операционной деятельностью по оказанию ИТ-услуг. DevOps можно рассматривать как продолжение гибкой разработки: она считается завершенной, когда код наконец написан и готов к развертыванию, но еще не развернут. Методика DevOps идет дальше: в ней много внимания уделяется тому, каким образом код может быть развернут, причем быстро и надежно, после чего передан в продуктивную эксплуатацию.

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

Созидательная культура подразумевает психологическую защищенность, благодаря чему в ИТ-команде люди трудятся с удовольствием, а стрессы снижены. В определенной мере это ответная реакция на то, что нередко происходит в ИТ-командах: если специалисты, занятые в операционной деятельности ИТ, длительное время чувствуют себя некомфортно, испытывают стрессы, вынуждены работать по ночам, то производительность труда падает. Возникает вопрос: как нормализовать работу в ИТ? Думаю, именно это определяет сейчас основное направление развития DevOps.

- Так ли нова парадигма DevOps?

Она лишь отчасти новая и представляет собой комбинацию нескольких известных парадигм. В частности, в DevOps используются принципы бережливого производства, гибкой разработки, культуры психологической защищенности, теории ограничений и ряд других. Таким образом, DevOps объединяет несколько подходов применительно к конкретной области для непрерывной интеграции и развертывания систем. Действительно новым в DevOps является сочетание перечисленных подходов.

- Многие из тех, кто говорят о DevOps, часто имеют в виду разные идеи. Возможно ли унифицировать представление разных людей о DevOps? И нужно ли?

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

- Каковы на сегодня наиболее сильные стороны DevOps?

Самая сильная сторона – это возможность использовать ИТ в интересах ИТ-специалистов. Я имею в виду автоматизацию процессов разработки. Еще одна сильная сторона в том, что DevOps смещает внимание ИТ-специалистов с инструментария на взаимодействие между людьми. Аббревиатура CALMS, которую ввел Джон Уиллис, включает основные принципы DevOps: культура (Culture), автоматизация (Automation), бережливое производство (Lean), измерение (Measurement) и обмен знаниями (Sharing). Как видим, автоматизация – лишь один из элементов DevOps. Эта методика мотивирует людей переосмыслить свою деятельность, в результате ИТ-команды приходят в движение, и это замечательно! DevOps оказывает очень мощное влияние на ИТ-индустрию.

- Многие специалисты говорят, что DevOps – это методика проектирования и разработки ИТ-систем. Корректно ли рассматривать DevOps шире – например, как культуру проектирования и выстраивания стоимостных цепочек?

Если вы взглянете на то, что содержится в руководстве «The DevOps Handbook», то заметите, что описанная в нем техническая практика во многом концентрируется на разработке и операционной деятельности – на том, чтобы подготовить код к развертыванию и сохранить его в репозитории. При этом базовая область DevOps не охватывает то, что должно предшествовать созданию кода и что должно происходить после того, как работа завершена, и продукт передан в продуктивную эксплуатацию и сопровождение. Думаю, сообщество специалистов по ITSM, впитавшее в себя более чем 30-летний опыт предоставления ИТ-сервисов, сможет обогатить сообщество DevOps дополнительными знаниями, и тогда мы получим более объемлющий взгляд на создание и внедрение ИТ-систем. Таким образом, DevOps в узком смысле – это технические практики, но, полагаю, дополнив эту методику культурными нормами и принципами совместного созидания, а также знаниями из области ITSM, мы сможем трактовать DevOps гораздо шире, выведя разработку на более высокий уровень.

- Как вы расцениваете попытки перенести принципы DevOps на управление операционной деятельностью в ИТ-командах и в бизнес-организациях, а также на управление проектами?

Совсем недавно мне довелось участвовать в обсуждении того, как принципы и опыт DevOps могли бы быть использованы для управления сервисами. Считаю, что это хорошая идея: и бизнес, и специалисты по управлению проектами используют принципы agile, которые зародились в среде разработчиков ПО. На мой взгляд, переносить любую методику (в том числе DevOps) на новую предметную область следует избирательно, осваивая и адаптируя то, что подходит и что полезно для новой области.

- Каких изменений и наработок можно ожидать в DevOps в обозримом будущем?

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

В Москве прошел пятнадцатый форум IT Management Forum, организованный издательством «Открытые системы» и собравший более 400 представителей отечественных и зарубежных компаний из разных отраслей зарождающейся цифровой экономики. Слоган форума – «Стратегия и практика управления ИТ. В ответе за цифровое предприятие» — весьма точно характеризует современное состояние процесса цифровой трансформации, которая не сводится к последовательной и уже привычной автоматизации. Сама по себе автоматизация не улучшает текущие бизнес-модели – за счет одного лишь применения новых технологий цифрового общества не построить, поэтому требуется, как считают участники сессии «Корпоративный Agile/DevOps и другие инновации в управлении», изменение культуры, профессиональное движение, нацеленное на изменение производственных отношений.

В форумах ITMF регулярно принимают участие ведущие зарубежные и отечественные эксперты. В этом году на форуме выступил Марк Смолли, всемирный посол фонда ASL BiSL и ассоциации DevOps Agile Skills, который на пленарном заседании задал вектор обсуждения вопроса о роли DevOps, сравнив, в частности, разговоры вокруг этой методологии с религиозными спорами, а именно, с дзэн-буддизмом.

Итак, что такое DevOps – культ романтиков, где на любого, пришедшего на обсуждение без принятых артефактов, смотрят с подозрением, либо это лишь рядовой метод разработки программного обеспечения, а может быть, это развивающееся профессиональное движение, нацеленное на укрепление производственных отношений между разработчиками и специалистами подразделения эксплуатации и ускорение выполнения запланированных работ?

В своем докладе «Первые шаги к DevOps и контроль качества ПО» Ольга Тимашева, руководитель центра компетенций по тестированию и обеспечению качества ПО «ЮниКредит Банка», рассказала о движении банка в сторону DevOps. В конце 2017 года была образована инициативная группа с привлечением команд разработчиков приложений, команды развития инфраструктуры и команды тестирования для реализации проекта объединения всех инициатив по автоматизации. В качестве основы на первых порах были выбраны некритичные для бизнеса приложения. Сразу выяснилось, что текущий способ управления изменениями не готов к процессам непрерывной доставки и развертывания, причем невозможно автоматизировать «человеческий фактор» в деле согласования изменений. Однако при развертывании тестовых сред вполне возможно минимизировать субъективизм, а для коллектива из молодых специалистов, стремящихся к освоению новых подходов, нет проблем при движении к DevOps.

Евгений Карасик, менеджер по продукту израильского центра разработок компании Micro Focus, отметил в своем докладе «Как мы внедряли DevOps. Рецепты успеха на основе личного опыта» важность ответственности всей команды за общее дело. Подход DevOps был выбран как способ реализации требований бизнеса за счет регулярной и ранней поставки ПО благодаря организации взаимодействия подразделений разработки, тестирования и эксплуатации. При этом продукты разрабатываются не только на основе принятых методологий, но и с учетом личного опыта разработчиков, а главный принцип звучал как «все,что может быть использовано более, чем один раз, должно быть автоматизировано». Следование DevOps позволяет выявлять и преодолевать организационные, технологические и психологические барьеры для создания управляемого и контролируемого прозрачного процессa с быстрой обратной связью. Однако нельзя делать DevOps наполовину, а эффект будет выше, если всем членам команды интересно работать «по душе, а не по карьерному росту», отметил Карасик. Если до перехода на DevOps новая версия продукта выходила раз в год, то после – по запросу бизнеса, технологический стек стал меняться теперь не раз в несколько лет, а по мере необходимости. Обычно объем кода увеличивался на 30% для каждой версии, а теперь максимум на 3-5%, причем автоматизация тестирования составила 80%, а не 20%, как раньше. Все это позволило резко повысить качество продукта.

Однако, несмотря на такие высокие показатели, не все докладчики сессии рекомендовали слушателям всегда следовать дорогой DevOps. Ирина Марчева, руководитель продуктового офиса компании «М.Видео», в своем выступлении «Нужен ли вам Agile?» обратила внимание на то, что внедрение DevOps не следует считать панацеей. Гибкие методологии итеративной разработки, например Scrum, эффективны в случаях, когда неясен результат и требуется быстро проверить различные гипотезы, а для классических, размеренных проектов с четкими сроками и целями достаточен инкрементальный, эволюционный подход. Проблема может возникнуть в крупных организациях, когда одна часть компании живет в парадигме Agile, а другая – в старой «водопадной», и здесь может помочь SAFe. Проект создания интернет-магазина «М.Видео» с его неясными целями и масштабами изначально относился к Agile, и, по словам Марчевой, его успеху способствовали поддержка со стороны руководства, привлечение консультантов и, главное, – предоставление команде права на ошибку.

Бизнесу нужны конкретные конкурентные преимущества, и ему в конечном счете нет дела до Agile как культуры, отметил в своем докладе «Покажи мне свои практики. Когда Agile краснеет» Олег Егоркин из «Ростелекома». Однако эффективность любой практики, а значит, и результаты бизнеса сильно зависят не только от возможностей команды, но и от способности самих бизнес-руководителей принять культурные преобразования. Свое выступление Егоркин построил вокруг общей многоуровневой модели развития организационной культуры – поведение всех сотрудников компании определяется ее принадлежностью к конкретному уровню: импульсивная (банда), конформистская (церковь), конкурентная (корпорация), плюралистическая (семья) и эволюционная (живой организм). В наибольшей степени практики DevOps начинают работать лишь на четвертом уровне, на втором Dev и Ops существуют раздельно, а на третьем появляется ITIL. Предложенная модель позволяет понять, готова ли команда к DevOps и имеет ли смысл перенимать практики у команд с более развитым культурным кодом.

Вслед за повсеместным принятием на предприятиях концепции DevOps, поддерживающей активное взаимодействие всех участников жизненного цикла приложений, сегодня заговорили и о DataOps — подходе, который обеспечивает «демократизацию» данных, позволяет работать с ними всем сотрудникам предприятия. Участники дискуссии постарались разобраться, что в DataOps от проходящей моды, а что от насущных потребностей.

Сам термин DataOps появился в 2015 году в блоге Энди Палмера, вместе с Майклом Стоунбрейкером основавшего компанию Tamr. В марте 2017 года термин прозвучал на конференции Strata+Hadoop World, организуемой O’Reilly, а вскоре прочно вошел в лексикон профильных периодических изданий, в частности в ИТ-глоссарии Gartner. Саму концепцию уже взяли на вооружение такие компании, как Facebook, Netflix, Uber, LinkedIn, Twitter и eBay, развернув под нее соответствующую инфраструктуру.

Термин был выбран достаточно удачно – все его понимают как применение практик быстрой интегрированной разработки и эксплуатации на больших объемах данных, однако в его трактовке возникают разногласия. Разрешить их и была призвана дискуссия «DataOps – agile-подходы к работе с данными», которую в рамках форума BIG DATA 2018 провел Андрей Николаенко из IBS.

В ходе дискуссии обсуждались, например, такие вопросы: agile-методологии в работе с большими данными: скрещивание модных терминов или насущная необходимость? «Бимодальные ИТ», большие данные и DataOps: можно ли развести процессы и данные — часть в «традиционный модус», часть в «гибкий цифровой»? Имеет ли смысл накопление данных при их неясной ценности для анализа в будущем? При обсуждении второго вопроса участники дискуссии рассмотрили ситуацию, когда все данные общие, но с ними одновременно надо работать двумя разными способами: традиционно, когда релизы приложений выходят раз в полгода, и в цифровом режиме, когда обновления происходят несколько раз в день. Анджей Аршавский, директор Центра анализа данных и математического моделирования НЛМК, вместе с Антоном Исаниным, руководителем центра качества «Альфа-Банка», подтвердили, что в их компаниях налицо бимодальность ИТ, но аккуратное выстраивание над платформой данных правильных переходников позволяет эффективно работать с единой платформой в двух режимах.

Наиболее оживленную полемику вызвал вопрос о выживании в условиях DataOps профессий аналитика, математика, программиста, тестировщика и администратора баз данных, поскольку этих специалистов потенциально могут заменить «универсальные солдаты» — исследователи данных (data scientist). Участники дискуссии опровергли тезис о том, что возможно слияние специализаций. Например, Вадим Индриков, начальник отдела системной архитектуры ГНИВЦ ФНС РФ, и Валерий Артемьев, консультант отдела разработки политик, стандартов и процедур Управления методологического и организационного обеспечения департамента статистики и управления данными Банка России, обратили внимание на то, что в командах скорой разработки очень важны взаимная страховка и понимание работы коллег. В этом смысле, как отметил Олег Егоркин, директор проектов «Ростелекома», важно владеть смежной квалификацией, но при этом само по себе понимание работы смежника и готовность его подстраховать вовсе не означает «универсализацию специализаций» – нельзя быть автомехаником, лишь обладая навыками замены колеса. Интересный момент по поводу слияния специализаций по работе с данными отметил Артем Данилов, архитектор хранилища данных в Avito.ru. Менеджеры по работе с посетителями портала Avito, сказал он, владеют SQL, составляют визуальные отчеты и с помощью запросов к базе постоянно решают возникающие нестандартные задачи, что, впрочем, не делает их разработчиками платформы данных, поскольку хранилище и витрины создают все-таки профильные специалисты.

Итак, по мнению участников дискуссии, чтобы «демократизировать» данные, нужно преобразовать как средства доступа к ним, так и способы управления данными, обеспечивающие коммуникации и интеграцию уже имеющихся данных, команд и систем. На решение этой задачи и направлена концепция DataOps — установление связи тех, кто собирает и готовит данные, с теми, кто их анализирует и применяет в бизнесе. Данные не принадлежат ИТ, специалистам по данным или аналитикам. Они принадлежит всему бизнесу, а инструменты самообслуживания должны позволять всем сотрудникам компании создавать собственные аналитические отчеты и визуализации, делясь своими открытиями с коллегами. В этой связи, как прогнозируют аналитики Gartner, уже в ближайшие годы 80% компаний из Global Fortune 1000 будут использовать в своей практике методологию DataOps.

Технический директор Hitachi Vantara Хью Йошида продолжает комментировать основные тенденции наступившего года в ИТ-индустрии. На этот раз речь идет не о технологиях, а о тех бизнес-процессах, что были запущены благодаря цифровой трансформации и сегодня помогают компаниям адаптироваться к новым экономическим реалиям.

• Начало: тенденции в области виртуализации и Интернета вещей >>>
• Продолжение: тенденции в области интеллектуального хранения данных >>>
• Продолжение: тенденции блокчейна, биометрии и видеоаналитики >>>

Хью Йошида: «Производители сегодня не могут тратить несколько лет на разработку технологии, а потребители не могут строить свой бизнес исходя из многолетних планов развития, которые не гарантируют получения того, что им нужно».

Совместное создание стоимости

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

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

Методология Agile

Методологией Agile называют такой подход к ведению бизнеса, при котором продукты или услуги компании регулярно меняются, дорабатываются и модернизируются исходя из рекомендаций конечных пользователей. Эта методология может затрагивать все процессы в компании – от организации ИТ до облика и характеристик продукта, который попадает к клиенту. Все это должно быть обеспечено поддержкой программного обеспечения и технологических решений, ориентированных на итеративную разработку, динамическое формирование требований и их скорейшую реализацию.

В последние десятилетия методология Agile развивается при разработке программного обеспечения, причем она часто применяется в сочетании с практиками DevOps. Если в центре внимания методологии Agile находятся главным образом процессы, то DevOps основной упор делает на автоматизированную сборку, автоматизированное тестирование, непрерывную интеграцию и непрерывную поставку технологий.

В 2018 году мы сможем наблюдать переход на методологию Agile и практики DevOps в области разработки программного обеспечения, при этом их применение распространится в масштабе всего предприятия. Мы знаем, что ключевые идеи цифровой трансформации компании – это, во-первых, максимальнакя финансовая эффективность и, во-вторых, взаимодействие между бизнесом и ИТ, способствующее созданию новых моделей управления компанией, выходу на более широкие рынки и поиску путей взаимодействия с клиентами.

ИТ-подразделение Hitachi Vantara применяло методологию Agile в течение последних двух лет, чтобы стимулировать цифровую трансформацию внутри компании. И результаты оказались весьма впечатляющими.

В подобных условиях переход к методологии Agile – стратегически верный шаг, поскольку множество ИТ-организаций работают по унаследованной разрозненной эксплуатационной схеме, когда администраторы, отвечающие за серверы, сеть, системы хранения данных, базы данных и облачные решения, передают друг другу данные о любых изменениях. Даже когда в ЦОД внедрялись технологии для создания совместных хранилищ данных и устранения этой разрозненности, различные функциональные подразделения по-прежнему фокусировались на своих собственных задачах, а не на задачах бизнеса компании в целом.

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

ИТ-подразделение Hitachi Vantara под руководством ИТ-директора Рене Маккасл применяло методологию Agile в течение последних двух лет, чтобы стимулировать цифровую трансформацию внутри компании. И результаты оказались весьма впечатляющими. Только за 2017 год наше ИТ-подразделение смогло перейти на новую CRM-систему, которая объединяет данные всех подразделений компании, а также перенести центр обработки данных из Индианаполиса на совместную площадку в Колорадо, откуда мы оказываем услуги дочерним компаниям Hitachi в Северной и Южной Америке. Кроме того, были обновлены веб-службы и благодаря этому налажено нормальное функционирование наших приложений на мобильных устройствах, нам также удалось объединить три компании – Hitachi Data Systems, Hitachi Insight Group и Pentaho – в единый проект Hitachi Vantara, при этом ребрендинг в наших электронных системах и службах поддержки клиентов по всему миру был проведен менее чем за 30 часов!

Во всех этих процессах ИТ-подразделение являлось частью более крупной схемы применения методологии Agile: наш директор по коммуникациям Мэри Энн Галло смогла объединить все заинтересованные в преобразованиях стороны – от отдела продаж до отдела кадров. Вместе они завершили процесс ребрендинга менее чем за 6 месяцев, тогда как по обычной схеме на него ушло бы более года. Таким образом, применение методологии Agile в Hitachi Vantara вышло за рамки разработки программного обеспечения и охватило всю организацию.