Маркус-Александр Функе, SAP
Дорожная карта жизненного цикла решения
Докладчик: Маркус-Александр Функе, SAP
Я уже говорил про ОСС — центр операционного управления. У нас, как в любой химической компании, все должно быть под контролем, так сказать, на кончиках пальцев рук, чтобы всем можно было управлять. Ранее мы рассматривали весь процесс — от создания прототипа до центра управления инновациями (ICC), в процессе рассмотрели управление тестами, документирование решений, прроанализировали, как Mission Control Center помогает справляться с решением вопросов в критически важных проектах, а теперь наступает волшебство — переходим к операционной деятельности и внедряем все в продуктив, надеясь, что бизнес будет доволен.
Центр оперативного управления, как правило, базируется в ИТ, и существует масса технических решений. Бизнес исходит из того, что все эти вещи должны приносить выгоду компании. Если вместо того, чтобы создавать дополнительную стоимость, ИТ оказывается в ситуации, когда приходится просто обрабатываете тикеты — это не очень‑то хорошее положение. Поэтому мы должны рассмотреть саму концепцию центра операционного управления, понять ее суть и выгоду такого центра в компании.
Вообще это все очень просто. Стабильный бизнес-процесс отображается здесь, потом возникает инцидент, и потом наступает время, в течение которого вы должны поднять систему. Чем быстрее вы это сделаете, и чем меньше влияние, меньше последствия, тем лучше. Как это сделать? С помощью проактивного анализа рисков, проактивного мониторинга, уведомления, то есть обнаружения таких проблемных мест до того, как они случаются. И, конечно же, есть еще одна вещь. Если это решение придумано для развития бизнеса, при повышении пропускной способности бизнеса должны соответствовать ему и пропускные способности IT-систем. Вот два основных вопроса: быстрое реагирование и правильное масштабирование.
Допустим, 1 минута простоя ключевого процесса обходится вам в 5 тысяч долларов — такой параметр был приведен в исследовании на informationweek.com. В любом случае, если процессы не работают, вы, например, выпекаете хлеб и выпекать его не можете, потому что транспортная система не снабжает вас сырьем для производства хлеба, или, например, вы управляете каким‑либо отделом у ритейлера бытовой электроники и не можете найти нужную стиральную машину, есть ли она в наличии или нет — так или иначе, если решения, которое поможет вам это обнаружить, нет, это влияет на ваш бизнес. Поэтому равна ли минута простоя потере 5 тысяч долларов или нет, это каждая компания должна определить для себя самостоятельно.
Когда мы приступаем к эксплуатации, идеальная ситуация выглядит следующим образом. Дело не только в функциональных требованиях: с ними проще всего, так как они отражают явные потребности бизнеса. Но чаще всего эксплуатировать систему мешают нефункциональные требования: возникают такие проблемы, как деградация качества сервиса, неэффективность, потеря стоимости и выгоды. Здесь стоит подумать о том, какие нефункциональные требования крайне важны для IT, а какие — для бизнеса. Так, я считаю, должна выглядеть ситуация, чтобы была абсолютно ясной и позволять действовать без промедления.
Дальше, что собой представляет концепция ОСС? Центр операционного управления — это не набор инструментов. Приведу пример: американская компания, которая тратила буквально миллионы долларов на то, чтобы установить у себя системы мониторинга SAP. Спустя год рентабельности от этих вложений не было никакой, потому что компания, внедряя системы, не интегрировала их с процессами, исполнителями. Многие клиенты не испытывают недостатка именно в инструментах, но проблема заключается в том, что они работают разрозненно, ИТ не общается с бизнесом, и это очень сложно изменить.
В худшем случае ИТ, не общаясь с бизнесом, не знает бизнес-требований, не определены актуальные релевантные процессы, сотрудники не подготовлены к тому, чего ожидать. В худшем случае оказывается, что уведомление приходит человеку, который не знает, что делать. В одном банке внедрили CRM «Business Partner», и репликация делалась в не саповскую систему, поэтому клиентские данные использовались. В ИТ-отделе получили уведомление об этом, но никто, к сожалению, не сказал сотруднику, что необходимо делать в случае получения такого уведомления. В конечном итоге возникла очень большая несогласованность, исправление которой обошлось компании в 2 миллиона долларов.
Зачастую не определены процессы, позволяющие решить, что делать в конкретной ситуации: всегда что‑то происходит в этом мире, и с подобными проблемами нужно уметь обращаться правильно. Предположим, есть нефункциональное требование, оно поступило в момент перехода к эксплуатации, но конкретно не определено. В результате, когда вам кажется, что все у вас получается сделать качественно и недорого, оказывается, что нужно еще поддерживать партнера, других специалистов в течение какого‑то времени, что обойдется вам в кругленькую сумму.
Переход к эксплуатации — это часть вашего большего проекта, и вы должны предугадать такую ситуацию и определить, какие нужно процессы мониторить, а какие нет. Для некоторых клиентов крайне важно, например, иметь одинаковое имя отклика по транзакциям. Допустим, Россия — очень большая страна, штаб-квартира компании может располагаться в Москве, а офисы где‑нибудь во Владивостоке. И человек, который работает из владивостокского офиса, должен иметь ту же самую эффективность транзакций, что и здесь, в Москве, хотя он находится за 7 часов от столицы. Люди могут заявить о том, что идут транзакции очень медленно, а в это время ваш IT-support, ваша IT-поддержка не занята делом. Так вот, возможно, нужно проверять эффективность работы системы и давать уведомления проактивно: что сейчас время отклика не 1 секунда, а больше, и параллельно вы пытаетесь понять, в чем заключается проблема — в локальной сети или у провайдера. Конечно же, это является частью общего мониторинга.
Определение центра операционного управления всегда отвечает на вопрос, каковы нефункциональные требования: например, производительность, доступность, бизнес-процессы. С помощью инструментов мы можем измерить различные КПЭ технические, несколько тысяч бизнес-КПЭ и прочих, но мониторинг таких КПЭ создает огромные объемы данных. Это не всегда стоит всегда делать, потому что нам нужно осуществлять мониторинг понятный и точный. Если что‑то произойдет, если нет процессов постоянного улучшения, то тогда нужно сделать так, чтобы эти вещи сразу же решались.
Этот центр управления создается как центр управления полетом. Здесь нужно визуализировать те КПЭ, которые являются наиболее понятными и важными для вашего бизнеса. Мы делаем много дашбордов, много панелей управления в Solution Manager, и этот набор инструментов предоставит вам средства для визуализации этих показателей. У нас даже стандартные сценарии доступны для того, чтобы использовать приложения для iPad.
Можно создать специальный фреймворк. Например, есть инструменты мониторинга сторонних производителей для отслеживания деловых КПЭ. Если вы используете такие решения, то, очевидно, движетесь в правильном направлении к созданию центра операционного управления. Основная идея этого центра заключается в том, чтобы у вас была платформа, которая может справляться с любыми уведомлениями одинаково. В целом ОСС, центр операционного управления, имеет такие сенсоры, датчики, сопряженные с бизнес-процессами: это бизнес-КПЭ в сочетании с техническими КПЭ, которые позволяют проверить, эффективно ли работают бизнес-процессы. Solution Manager сам по себе в нынешних релизах делает это максимально стандартным: есть единая платформа, на которой вы получаете все уведомления, не важно, с какого уровня, и решаете проблемы интегрированно. ОСС — это не набор отдельных инструментов, а платформа, которая помогает правильно реализовать критично важные для бизнеса процессы.
Теперь мы, надеюсь, понимаем, что такое ОСС, что такое центр операционного управления, как он может выглядеть. У проектной команды одна цель — изменения: они хотят добиться изменений, но проект пока не завершен, нужно вносить в него коррективы. А вот, например, системный администратор вряд ли дозволит какие‑либо перемены. Они оба правы, только нужно их правильно сбалансировать и сделать это разумно, и в переходе к эксплуатации это крайне важно.
Как мы осуществляем переход к эксплуатации, к продуктивному режиму? Самое важное здесь заключается в том, что функциональные стандарты должны соблюдаться. Переход к эксплуатации, к продуктивному режиму подразумевает следование определенным принципам. Если у вас нет принципов эксплуатации, стандартов, то это внедрение. Наверняка у вас есть одно решение, оно реализовано, есть, например, переход спланированный, чтобы скедьюлинг-интерфейс был создан и интегрирован. Когда мы реализуем новый проект, новое SAP-решение внедряем — например, SAP HANA, это всегда дает возможность подумать об эффективности использования таких систем, об эффективности работы.
Подготовка к такому изменению в организации должна осуществляться параллельно. В конечном итоге, когда мы будем эксплуатировать систему, мы увидим, что некоторые вещи не стыкуются, не работают вместе, поэтому передача знаний, поддержка процессов и тестирование очень важны для того, чтобы наладить эту архитектуру правильно, это важные элементы. Мы должны применять те же принципы тестирования, чтобы не возникло непонимания между командой внедрения и командой эксплуатации, чтобы мониторинг системы тоже был передан специалистам по эксплуатации после выхода в продуктив.
Таких новых проектов, абсолютно новых, сейчас не так и много. В целом важно понять, где возникают или могут возникнуть разрывы, найти их и идентифицировать,