Компания «Чайная ложка» – одна из наиболее динамично развивающихся сетей общественного питания в России. Создана она в 2001 году и на сегодняшний день насчитывает 53 чайных – 44 в Санкт-Петербурге и девять в регионах, а также фабрику и офис. Лидер отечественного фастфуда в северной столице сделал ставку на традиционно русское меню. В планах компании -- к 2011 году стать национальным оператором, расширить сеть как минимум до четырёхсот чайных по всей России и даже провести экспансию русских блинов на международный рынок фастфуда. При этом традиции русской кулинарии поддерживаются с помощью самых современных ИТ. В нынешнем году в «Чайной ложке» был создан новый ЦОД, обеспечивающий автоматизацию растущего бизнеса. Об этом рассказывает ИТ-директор компании «Чайная ложка» Эдуард Шишмарев.

Intelligent Enterprise: Как проходила автоматизация сети «Чайная ложка»?

Эдуард Шишмарев: 2007-й стал для нашей компании годом экспансии в регионы -- по словам одного из наших руководителей, теперь мы из первой лиги перешли в высшую. Основная ставка была сделана на технологии. Когда я пришел сюда три года назад, в чайных никакой автоматизации по сути не было, заказы принимались «на бумажках». В 2006-м перед нами появилась цель -- стать федеральной компанией, и без возможности оперативно представлять управленческую информацию было уже не обойтись. А значит, не обойтись и без ЦОДа. Мой подход состоит в том, что начинать нужно с инфраструктуры. Поэтому сначала мы все чайные объединили в VPN-сеть, обеспечив каналы связи, для чего был заключен контракт с компанией Golden Telecom. Тогда мы еще не думали о ERP-системе и занимались главным образом POS-терминалами в чайных.

С какими проблемами вы столкнулись при выборе решений для точек питания?

Прежде всего, перед нами стоял вопрос, какое ПО ставить в POS-терминал. Наши технологии обслуживания гостей (именно так мы называем посетителей и клиентов) и требования к скорости обслуживания не нашли отражения в существовавших POS-системах на рынке ни по функционалу, ни по стоимости доработки. Поэтому мы решили разрабатывать софт самостоятельно. Кроме того, готовые POS-решения имеют значительные ограничения по изменению интерфейса, а у нас к интерфейсам особые требования. Например, для обеспечения максимальной скорости работы сотрудников чайных нельзя, чтобы в меню было больше двух уровней глубины, необходимы особые кнопки под правую и левую руку и т. п. А сейчас нужны дополнения в связи с разработками наших маркетологов: за покупателей уже нужно бороться, вводить системы скидок, «счастливые часы», карточки покупателя.

Есть и еще один аспект: в чайных всегда идет борьба за пространство; лишний квадратный метр – это лишний столик, а значит, больше обслуженных клиентов. Поэтому размещать там оборудование и негде, и дорого. Мы не могли устанавливать там отдельные серверы, как в супермаркете. В каждой чайной есть свой менеджер и свой компьютер, чтобы вести учет, вводить какие-то данные и получать почту. Но сами POS-системы -- терминальные. Таким образом, наши точки находятся в единой сети и из центрального офиса рассматриваются как «единый супермаркет». И мы в онлайновом режиме видим каждый пробитый на кассе чек.

А на какой платформе вы автоматизировали основные учетные функции и бизнес-процессы?

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

Была и еще одна причина, по которой мы нуждались в новой учетной системе, – это специфика наших расходов на заработную плату персонала. Зарплата – одна из основных статей расходов компании. Работает у нас в основном молодежь, студенты, и оплата почасовая. Раньше в каждой чайной управляющий просто записывал, кто сколько проработал. Однако понятно, что в наших масштабах даже минуты неточности в учете этого времени превращаются в огромные потери. Поэтому нам была нужна система учета рабочего времени. Готовые такие системы предназначены для офиса, где сотрудник «прокатывает» карточку по приходе и то же самое делает, уходя. Нам это не подходит. У нас есть своя специфика. Например, существует параметр – число клиентов в час. Есть и нормы по количеству работающих сотрудников в зависимости от потока посетителей. Утром весь персонал в зале не нужен, а вечером, в час «пик», наоборот, иногда даже приходится привлекать сотрудников из других чайных. Наша собственная система для этого формирует план их выхода, электронный табель и ведет контроль. А по итогам работы рассчитывается зарплата.

Так по мере усложнения задач по учёту хозяйственной деятельности прорисовывались требования к формированию учётной информации в единой системе. Поэтому мы решили, что нам нужна полноценная ERP-система, с ее механизмами управления товарными запасами, логистикой, а также модулем бюджетирования (поскольку мы привлекаем дополнительные инвестиции в бизнес, нам было важно обеспечить план-фактный анализ). Во второй половине 2006 года мы стали выбирать ERP-решение. Рассматривали мы «1С:Предприятие» 8.0 и Microsoft Dynamics АХ (Axapta). У более дорогих систем, как ни странно, вообще не оказалось функциональности, подходящей для предприятий фастфуда. Мы выбрали Microsoft Axapta и компанию-внедренца -- Columbus IT. И соответственно встала задача создания ЦОДа для ERP-системы.

Расскажите, как создавался новый ЦОД.

Мы подсчитали, сколько у нас примерно чековых транзакций, -- как я уже говорил, каждый чек, пробиваемый в любой из наших чайных на территории России, попадает хотя и не непосредственно в ERP-систему, но в специальное связанное с ней хранилище данных. Кроме ввода чеков к системе пойдут постоянные аналитические запросы. Поэтому у нас было выставлено серьезное требование по высокой скорости работы ЦОДа. Cпециалисты из Columbus IT определили, какое «железо» нам будет нужно для безотказной работы ERP-системы, и провели сайзинг оборудования.

В итоге была выбрана следующая архитектура: серверы базы данных (Microsoft SQL Server) и приложений (Axapta Object Server, составляющий основу Microsoft Dynamics AX) размещаются на блейд-серверах, сами данные размещаются на внешних хранилищах, соединённых с фермой блейд-серверов оптическими каналами для достижения абсолютной производительности. Мы выбрали оборудование IBM, и тому было три причины. Во-первых, у них есть офис в Санкт-Петербурге, во-вторых, этот вендор занимается блейд-серверами, а в-третьих, в Санкт-Петербурге работает партнер IBM, который мог стать для нас надежной поддержкой по разработке решения и его дальнейшему обслуживанию -- это компания Trinity. Таким образом у нас получилась конфигурация из IBM Blade Center и системы хранения IBM TotalStorage DS4800.

По нашим подсчетам у нас оказывалось много различных приложений: SQL-сервер, Microsoft Dynamics AX, серверы различных приложений, терминальные серверы. Поэтому мы могли сразу заполнить все четырнадцать полок шкафа. Кроме того, сейчас в нашей серверной находится телефонная станция и оборудование инфраструктуры связи.

Работы по проекту начались в декабре 2006 года, а в апреле 2007-го мы должны были переехать в новый офис и сразу перейти к работе на базе нового ЦОДа. И к апрелю проект создания ЦОДа был завершен, хотя далеко не всё удалось настроить сразу – ведь в Санкт-Петербурге не так много подобных решений, и в чем-то наш ЦОД был уникален даже для специалистов компании Trinity, которая проектировала и строила его вместе с нами.

Как обеспечивается отказоустойчивость всей корпоративной информационной системы?

Как ни странно, наш ЦОД не является самым «узким» местом в обеспечении непрерывности бизнеса компании. Для нас главное -- чтобы работали кассы в чайных. А это зависит только от подачи электричества. Даже если ЦОД выйдет из строя, чайная может 48 часов работать автономно, а потом эта информация просто «сливается» в центральное хранилище. Есть, кстати, у нас и такие чайные, где не проложена VPN, и там мы работаем через сотовую связь сеансами dial-up, то есть по сути именно по такой «сеансовой» схеме. Так что и в случае выхода из строя ЦОДа или проблем у оператора связи определенный запас времени у нас есть.

Но, разумеется, хотя ИТ-инфраструктура и ЦОД -- не самое слабое звено, проблема отказоустойчивости оборудования была для нас одной из самых важных при выборе. Статистика показывает, что отказы блейд-систем сведены практически к нулю. В России такие случаи мне, например, не известны. Причем у нас все равно есть и резервные блоки питания, и вентиляторы. В серверной обеспечена подача электропитания мощностью 10 кВт, установлен ИБП компании APC. Мы уже имели возможность убедиться в надежности ЦОДа при отключении электричества. Недавно Ленэнерго обесточило наше здание, и системы сработали нормально, все приложения и серверы ЦОДа сами аккуратно завершили работу и затем включились. Мы бы вряд ли решились провести такие рискованные «учения», но городские службы нам не оставили выбора. Так что риск остановки ЦОДа скорее носит форс-мажорный характер.

Какие организованы процедуры резервного копирования данных?

Сейчас для этого предназначен отдельно стоящий сервер. Резервное копирование данных происходит раз в сутки ночью. Причем в конце недели уничтожаются предыдущие шесть копий, а в конце месяца – соответственно все копии за прошедший месяц. Таким образом, у нас всегда есть копии за все месяцы плюс за все дни текущей недели. Причем это защита не от сбоя приложений, а скорее «от дурака» -- если кто-то из пользователей случайно что-то сотрёт. Именно поэтому мы отказались от «файловой помойки», общего сервера для хранения данных пользователей, переведя всё в Microsoft SharePoint. Структура Microsoft SharePoint, Microsoft Dynamics AX и нашей системы электронного документооборота DocsVision такова, что в них есть свои механизмы защиты данных, и это создает дополнительную степень общей защиты. Тем не менее следующим этапом обеспечения безопасности данных будет система back-up вне ЦОДа, «зеркало» будет находиться либо в Санкт-Петербурге, либо в Москве.

Окупают ли себя затраты на организацию VPN?

Действительно, для обычного ресторана столько VPN-портов было бы неподъемно по стоимости, ведь один порт обходится в 200 долларов в месяц. Но мы ищем пути окупаемости. В 2007 году были объединены и телефонные сети всех наших офисов, и теперь в Новосибирск и Москву можно звонить просто по внутреннему телефону. Это особенно полезно для маретинговых служб, все совещания они проводят с помощью функции громкой связи.

Если в Санкт-Петербурге до любой чайной менеджер может добраться за 40 минут, то в центральном регионе для того, чтобы из Москвы попасть, например, в Калугу или Обнинск, нужен целый день. Поэтому у нас есть видеокамеры, чтобы менеджер мог наблюдать в дистанционном режиме, что происходит в чайных, а VPN-инфраструктура позволяет организовать видеопоток. Еще у нас есть свое веб-радио, музыка, которая звучит во всех наших чайных. Это единый плей-лист со своими джинглами и объявлениями, разработанный специально для нашей сети. Есть планы продавать на этом внутреннем радио рекламу, что может полностью окупить затраты на системы связи.

Как вы планируете развивать ЦОД дальше?

На данный момент можно говорить об определенной избыточности: Microsoft Dynamics AX, на медленную работу которой обычно жалуются, у нас просто «летает». Однако расширение все равно нас ждет. И здесь спасибо блейд-технологии – мы просто добавим еще одно «лезвие», и всё. Это очень просто и быстро. Есть у нас место и для дополнительных шкафов.

С увеличением числа чайных будет увеличиваться число пользователей в филиалах, а значит, и количество терминальных серверов. Мы добавляем специальный сервер для каждого филиала, так как в самом филиале свои только офисные и почтовые приложения, все остальное находится в ЦОДе. Применять терминальные решения я сам агитировал руководство компании. И делал расчет их себестоимости на 5 лет, который показал, что даже при всех недостатках они выгодны. Да, мы заложили время простоя ЦОДа при форс-мажорных ситуациях. Но в целом терминальные решения очень удобны. Помимо торговых точек в терминальном режиме работают и сотрудники центрального офиса. За исключением отдельных специалистов (например, дизайнеров) они пользуются конкретным набором приложений, которые работают на серверах ЦОДа. Из 120 сотрудников офиса только четырнадцать работают «автономно», остальные – терминально. Через веб-доступ мы доставляем приложения и в регионы. Так, документы у нас хранятся в DocsVision, сервер которого доступен для всех региональных офисов. Например, сотрудник из Новосибирска в соответствующем модуле ведет учет персонала.

Нынешним ЦОДом мы сможем пользоваться примерно до 2009 года, он позволяет обеспечить работу двухсот наших торговых точек. Но к 2011-му, когда мы планируем открыть четыреста чайных по всей России, это будет уже другая стратегия, и нам понадобится несколько региональных ЦОДов.

А каковы в целом перспективы развития ИТ в «Чайной ложке»?

На мой взгляд, ИТ-стратегия имеет три составляющие – это системная инфраструктура, сервис и приложения. В области инфраструктурных изменений нас ждет переход чайных на Linux. Во-первых, это защитит систему от слишком пытливых и любопытных работников, и к тому же Linux более отказоустойчива. Для Microsoft Dynamics AX в терминальном режиме совершенно неважно, какая операционная система у терминала, – Windows или Linux. Кроме того, нам нужно коробочное решение для чайных, поскольку мы будем продавать франшизу. В настоящее время на открытие каждой чайной должен выезжать наш ИТ-специалист, Linux эту схему позволит упростить. Сейчас под Linux работает одна экспериметальная точка, но в 2008 году мы планируем перевести на неё все наши чайные. А что касается ИТ-инфраструктуры, мы будем развивать ЦОД в сторону большей отказоустойчивости, создавать резервное «зеркало», а также внедрять новые системы хранения данных.

С ростом бизнеса рождаются новые задачи, а значит, нужны и новые приложения для обслуживания возникающих идей. В далекой перспективе мы планируем внедрение BI-решений. Пока, конечно, неясен масштаб такого внедрения. Сейчас мы используем Microsoft Analyser, и для наших нескольких форм отчетов его вполне хватает. Нам надо понять, нужно ли нам мощное BI-решение, смогут ли наши пользователи загрузить его задачами.

Наокнец, в области организации нашей работы мы будем ориентироваться на методологию ITIL/ITSM. Нужно все наши филиалы обеспечить точной технологией обслуживания ИТ-инфраструктуры с наименьшими затратами. Кроме того, мы многое готовы отдать на аутсорсинг. Уже сейчас наши принтеры обслуживает внешняя компания. Теперь хотим отдать «вовне» и обслуживание POS-терминалов. Систему Axapta мы поручили внедрявшей ее Columbus IT. Нам не просто дорого обходится специалист по Axapta, нам не по карману поддерживать культуру изменений в ERP-системе, это ведь методология документирования со всеми вытекающими последствиями. Зависеть от одного программиста слишком опасно.

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

Красивое и продуманное решение

По словам Дмитрия Гриневича, директора по развитию бизнеса Trinity, решение в «Чайной ложке» было одним из самых продуманных. «Проектируя его, кроме требований заказчика мы опирались на два постулата: первый — все дело в мелочах и второй — красивая вещь хорошо работает, — комментирует Дмитрий Гриневич. — Прежде всего это не распределенное решение, а централизованное. Это повышает требования к отказоустойчивости. Поэтому мы остановились на следующей архитектуре: все серверы, которые располагаются в ЦОД, — это бездисковые блейд-серверы, которые работают с централизованным дисковым массивом. Архитектура блейд-серверов позволяет создать расширяемое и масштабируемое решение. Кроме того, эта технология уменьшает стоимость владения системой. Сейчас система управляется одним администратором, для такой распределенной сети это достаточно большая экономия». Для предоставления различных информационных сервисов были задействованы серверы-лезвия в двух- и четырехпроцессорной конфигурации. Характерной особенностью этого решения являются бездисковые конфигурации серверов — загрузка ОС и вся работа с данными осуществляется непосредственно с дискового массива.

Ядром всей ИТ-инфраструктуры являлось хранилище среднего уровня данных IBM TotalStorage DS4800, обладающее соответствующим уровнем надежности. Массив имел характерную особенность — у него было две полки диков различных типов: «быстрые» (FibreChanel) и «медленные» (SATA), что позволяет совместно с виртуализацией данных оптимальным образом использовать дисковое пространство в зависимости от задачи, а также при необходимости легко передавать ресурсы хранения от одного вычислительного ресурса другому. На SATA-дисках находились загрузочные образы систем, непосредственно для хранения данных использовались диски FibreChanel для обеспечения высокой производительности. Несмотря на то, что SATA-диски относительно медленные, их количество и организация уровня RAID позволяли обеспечить достаточно высокую производительность всего решения.