Предисловие
Коротко расскажу, чем занимается наша компания. Это, в первую очередь, сеть автозаправочных станций – 83 АЗС, несколько нефтебаз, газовые комплексы и обеспечение переработки нефти на белорусских НПЗ.
Основная платформа автоматизации – 1С, основные учетные функции реализованы в конфигурации «Управление производственным предприятием». Но сразу сделаю поправку – сами заправки работают на автономных кассовых решениях, с 1С не связанных. Это для понимания, почему мы могли или не могли делать определенные вещи.
Мой доклад о том, как мы трансформировали нашу информационную систему из состояния «А» в состояние «Б». Я не так давно работаю в компании – с конца 2017 года, и вместе со мной обновилась ИТ-команда. Поэтому на многие вопросы, например, почему информационная система находилась в состоянии «А», я не смогу ответить. Мы даже для себя выработали шутливый паттерн «исторически так сложилось». Я думаю, многие бывают в такой ситуации, когда у вас «исторически так сложилось»: что-то построено и работает не так, как вам хотелось бы, или это не удовлетворяет бизнес сегодня.
На предприятии работает 1 300 человек, из них около 350 – активные пользователи информационной системы, в частности системы УПП. И прямо в воздухе витала общая неудовлетворенность работой системы – УПП работала медленно и не очень стабильно. И хотя все это знали, почему-то очень длительный период ничего по этому поводу не предпринималось.
Поэтому когда я пришел на предприятие, одной из приоритетных задач нашей новой команды ИТ-специалистов стало устранение неудовлетворенности, трансформация системы в удовлетворительное состояние.
О системе
Я как математик по образованию люблю формализовать задачи, формулировать требования и то, что у нас есть. Поэтому первое, что мы сделали, – записали «Дано на август 2018 года»:
- сильно кастомизированная УПП на платформе 8.1;
- база данных в MS SQL 2008 размером 1.2 ТВ с ошибками логической целостности (CHECKDB не проходит);
- сервер 1С и SQL на разных виртуальных машинах в кластере VmWare;
- около 300 активных пользователей, которые постоянно работают в базе в режиме 12х7. Тут стоит оговориться, режим многих распределенных объектов 24х7, но мы договорились, что бизнес-критичное время – это 12 часов, с 7 утра до 7 вечера. В это время база должна работать стабильно, и мы не можем вмешиваться в работоспособность, если только не появились какие-то критические вещи;
- 2 специалиста 1С – сильный разработчик и сильный аналитик-консультант. Эти ребята пришли в компанию вместе со мной, мы с ними работаем давно, поэтому в их компетентности я не сомневался и делал на них очень большую ставку.
Проблематика – все работает медленно и периодически падает. Это классическая проблема.
Одна из моих миссий, как ИТ-руководителя на предприятии, – это переводить бизнесу, из-за чего возникают трудности в ИТ и объяснять своим коллегам, что хочет бизнес, почему его не устраивают те или иные вещи.
Но иногда руководителям трудно объяснить, что происходит в ИТ, поэтому приходится импровизировать, придумывать какие-то аналогии. Мне в этом часто помогает визуализация.
Вот реальная картинка общего состояния нашей информационной системы в состоянии «А».
Я реально на совещании показывал этот автобус и говорил, что мы работаем примерно так, как этот старый автобус. Наверное, многие на нем катались в свое время. Не очень комфортно на этом автобусе было перемещаться, не очень быстро он ездит. Видно, что он не обслуживается, еще эта гармошка тянется и явно мешает автобусу передвигаться.
С этого и начинали.
Отдельно стоит отметить, что мы сначала построили, а потом уже сделали этот доклад. Поэтому какие-то вещи вносились уже постфактум.
Помимо того, что система работала неудовлетворительно, большинство пользователей знали, что конкретно не так, и что надо исправить.
Я могу предположить, что первые два пункта этого списка появились после работы с франчайзи или с внутренними ИТ-специалистами.
- Первое, на что ссылались, – слишком большая база, поэтому все тормозит.
- Второе – классический тезис – старые медленные сервера, их надо менять, поэтому все тормозит.
- Особо негативно настроенные пользователи, люди, у которых сложился негативный опыт, говорили, что 1С не может работать быстро, нужно внедрять SAP. Сами понимаете, Лукойл – компания достаточно большая, и ресурсы позволяют. Поэтому было движение, подталкивающее к внедрению другой системы.
Установив проблематику, мы понимали, что любое из решений требует внимательного подхода и тонкой настройки, поэтому разделили процесс изменения системы на четыре стадии:
- На первом этапе мы решали проблему железа и инфраструктуры;
- На втором этапе разбирались с платформой;
- На третьем – улучшали код;
- И на четвертом этапе – меняли процессы.
Этап первый – железо
Поскольку свою карьеру в ИТ я начинал как системный администратор, мне на первом этапе было понятно, что архитектурная конфигурация работы 1С и SQL-сервера у нас была неправильной – начиная от виртуализации и заканчивая разнесением на разные машины.
Поэтому мы разобрали виртуальный кластер, выделили из него достаточно мощный физический сервер, на нем установили операционную систему, сервер 1С и SQL. Сделали все настройки по Best Practices – Shared Memory, разнесли лог и файлы базы данных по разным дискам, и т.п. Все, что можно было выжать из этого железа, сделали. И в принципе, больших просадок по производительности в мониторе ресурсов не было. Но отдельно скажу, что железо было старое, 2011 года, и SSD там не было. Поэтому в пике по очереди к дискам могли быть большие задержки.
Вторая проблема – это большая база данных и не очень хорошее ее состояние. Тут стоит отметить, что большая база данных при не очень хорошем железе и не очень современной инфраструктуре – это проблема не столько скорости, сколько неэффективности проведения с ней регламентных операций по времени. Сами представьте, бэкап базы в 1.2 ТВ занимает много времени, на не очень быстрых дисках еще больше времени, а если вам нужно что-то оперативно развернуть из бэкапа, это сразу потребует несколько часов. Плюс 1С-ники не любят работать с конфигурациями без данных, поэтому несколько тестовых баз в пару терабайтов – это тоже большая проблема. Не говоря уже про постоянное обновление этих баз.
Как мы это решили? Я прекрасно понимал, что самостоятельно с этой задачей мы не справимся, поэтому нужно искать специалистов. У меня были хорошие контакты с ребятами из команды gilev.ru – в 2015 году я у них учился на курсе по оптимизации производительности. Мы с ними пообщались, и они сказали, что возьмутся за решение нашей проблемы. Основной фактор, по которому мы выбрали именно этих ребят, – это фиксированная стоимость услуг и понимание уровня компетенций специалистов. У них на сайте есть прайс, где можно увидеть, сколько реально стоит та или иная операция. Когда мы пробовали обращаться или консультироваться с фирмами-франчайзи у нас на локальном рынке, нам сначала предлагали провести аудит за много денег и никто не мог назвать сразу ни конкретные сроки, ни сумму, ни то, что получится в результате. А Дмитрий Юхтимовский из команды gilev.ru достаточно быстро нам определил стоимость для ожидаемого результата.
Процесс подготовки, настройки, выверки у нас занял примерно месяц – я на этом не буду долго останавливаться. А потом достаточно быстро – за два дня в два этапа, учитывая наши производственные мощности и технологическое окно, все ненужные регистры в базе были свернуты на июль 2016 года. В этот момент в Беларуси произошла деноминация, четыре нуля от нашей валюты были отрезаны, и те данные в нашей новой базе были уже не нужны.
Все прошло штатно. Но надо обметить, что обрезка базы почти никак не повлияла на производительность и скорость работы. Никак. Как оно работало, так и работало. Поэтому если у кого-то есть предположение, что ваша база работает медленно именно из-за большого объема, скорее всего, это не так. Скорее всего, проблема где-то в другом месте, надо искать узкие места.
Но были и два позитивных результата:
- Первый – для меня было очень хорошо то, что база после обрезки начала проходить check database. То есть проблема была именно в тех данных, которые мы в конечном итоге отрезали, и головная боль, как вылечить базу, пропала.
- Во-вторых, объем базы сократился примерно до 400 гигабайт. Это сильно упростило развертывание тестовых баз, сильно сократило время на регламенты и высвободило необходимые ресурсы.
Чтобы полностью завершить первый этап и развеять мифы о том, что все работает плохо из-за старых серверов 2011 года, мы в январе 2019 купили новые сервера. Там все сделали по рекомендациям ИТС или gilev.ru – SSD-диски, разделенные mdf- и lgf-файлы, много оперативной памяти и т.д.
Подытожу первый этап:
- После того, как мы переехали на новый сервер и свернули базу, мои коллеги (администраторы, разработчики 1С) заметили, что база стала работать чуть стабильнее, стали быстрее выполняться какие-то регламентные операции.
- Но как вы думаете, что сказали пользователи? Они сказали, что стало хуже и мы вообще зря на все это время тратили вместо того, чтобы сделать еще один отчет. Чтобы объяснить им, что произошло, мне опять пришла на помощь визуализация, я показал им такую картинку – автобус остался примерно тот же, но из него убрали лишнюю гармошку, покрасили, поставили новый двигатель. Но это остался тот же автобус, на той же платформе, на том же шасси. Стало комфортнее, но это не то, к чему мы стремились, и не то, ради чего все затевалась.
Если подводить итог, то первый этап был необходимым условием, но недостаточным.
Инструменты оптимизации
В январе 2019 года мы понимали, что все дальнейшие изменения будут более сложными именно с точки зрения аналитики и объяснения пользователям и руководителям, что мы будем делать. Поэтому нам нужны были инструменты оптимизации и поддержка руководителя, в частности генерального директора.
В качестве инструментов мы выбрали:
- Корпоративную подписку на сервис gilev.ru – это не реклама, мы ими действительно пользуемся до сих пор. На конференции много рассказывали про ЦКК, другие сервисы 1С, но для нас оказалось удобнее и эффективнее использовать именно сервисы gilev.ru. Многие из них бесплатные, но некоторые, которые входят в корпоративную подписку, дополнительно еще настраиваются и поддерживаются со стороны команды gilev.ru. В подписку входят такие сервисы, как:
- сервис производительности Apdex;
- сервис анализа логов технологического журнала;
- анализ долгих запросов;
- анализ состояния SQL базы;
- контроль загруженности оборудования;
- контроль взаимоблокировок – все то, чем нам только предстояло заняться и с чем работать.
- Отдельно рекомендую курс по оптимизации производительности Андрея Бурмистрова. Мне удалось лично побывать на многих курсах по оптимизации производительности, в том числе от 1С, но это были курсы именно администрирования. А для своих специалистов, на которых упала эта задача, мы приобрели удаленный курс Андрея Бурмистрова – очень подробный хороший курс, который описывает на уровне понимания, что нужно сделать. В частности, он является одним из этапов подготовки к сертификату 1С:Эксперт. Очень рекомендую.
- И еще один административный инструмент – мы договорились с генеральным директором на полгода наложить запрет на доработки конфигурации информационной системы. И хотя стек доработок очень большой, очень много функциональности, мне удалось объяснить и доказать, что на непрочном фундаменте нельзя достраивать этажи, нельзя развивать конфигурацию, потому что в конечном итоге все точно упадет, и риск потерять данные будет слишком большой – в этом случае простои будут очень большие.
Замеры производительности
Подробно про APDEX много было рассказано, поэтому не буду долго останавливаться. Скажу только, что это методология, которая призвана оценить уровень удовлетворенности пользователей производительностью системы. Не обязательно 1С.
Представление APDEX мы выбрали именно в таком виде – это скриншот сервиса gilev.ru.
Общее, что нужно понять с этой картинки, – красные области на этом графике отмечают, что по основным пунктам состояние работы системы неудовлетворительное.
В конце графика видна общая картина за день. В выходные у нас хорошо, а потом – плохо, плохо, плохо.
Видно, что общая оценка производительности системы плохая. Мы четко можем констатировать, что проблема есть, она реальная, вопрос «работает / не работает» не стоит, но чтобы исправить эту ситуацию, нужно, как сказал наш президент, «раздеваться и работать».
Второй этап – платформа
На следующем этапе нам нужно было перевести базу УПП на новую платформу 1С.
Все представляют, что 1С платформа – это оболочка над базой данных, которая, по сути, туда записывает и достает оттуда данные, показывая их в нужном виде. И именно от того, насколько качественно и хорошо платформа взаимодействует с базой данных, зависит производительность и удовлетворенность пользователей работой системы.
- Мы самостоятельно с помощью небольших манипуляций осуществили обновление платформы с 8.1 на 8.2. Сначала развернули тестовую базу и перевели для нее платформу. То, что вывалилось, сразу поправили самостоятельно. Потом сделали бета-тестирование: для этого разослали информационные письма и обзвонили ключевых руководителей с просьбой зайти в базу и совершить какие-нибудь свои классические операции (провести документ, сформировать отчеты), а если что-то не работает, прислать нам фидбэк, чтобы мы оперативно все исправили. Конечно же, в момент уже реального перехода появились новые ошибки, которые мешали работать, но они достаточно быстро были исправлены нашими программистами. Да, пришлось немного динамически обновить конфигурацию, но мы с этим справились.
- Второй большой этап заключался в том, что мы перевели базу на управляемые блокировки. Сразу анонсирую, что эта вещь очень сильно влияет на производительность, имеет очень большой эффект и вклад в трансформацию состояния из неудовлетворительного в положительное. Речь про перевод старой конфигурации из режима неуправляемых (автоматических) блокировок, когда блокировками управляет SQL Server, в управляемый – когда вы управляете этим сами на уровне кода. Делали мы это не сами, потому что хорошего практического опыта у нас не было. Обратились к подрядчикам, к той же команде gilev.ru, они нам все достаточно быстро, в течение пары недель, реализовали. Это дало сразу большой скачок по APDEX.
- На следующем этапе мы обновили платформу с 8.2 на 8.3.10, но без режима совместимости. Это тоже очень важно, потому что с 8.3.10 включается механизм версионирования на уровне SQL, что тоже сильно влияет на производительность, особенно на многопоточную обработку информации от различных пользователей.
Традиционная картинка. После каждого этапа, который занимал достаточно длительный промежуток времени, мы делали точечные доклады для бизнеса, чтобы показать, что платформа стала новее (автобус – симпатичнее).
На этом этапе многие из пользователей заметили улучшения, даже благодарили. Но, конечно были и те, кому результат не понравился, потому что раньше значок 1С был квадратный, а теперь стал круглый, цвет интерфейса был одного оттенка желтого, а теперь другого, шрифт изменился ит.п.. В общем, в базе стало невозможно работать. Тут я утрирую, конечно, но суть вы поняли.
А мы помним, что у нас есть APDEX, который дает объективную оценку нашей работе.
Третий этап – код
Третий этап я уже называю спецоперацией. Если до этого были масштабные акции и боевые действия, которые все видели и все знали, то код – это уже точечные спецоперации по конкретным узким местам, которые не давали быстро работать базе.
- Проводились спецоперации по корректировке регистров. Мы выявили, что еще с 10-12 регистрами было что-то не так, потому что когда регистр накопления копит-копит-копит, и по нему нет ни одной расходной операции, он не схлопывается в ноль, а там миллионы каких-то записей – явно что-то не так на уровне кода. Также нашли много регистров сведений, которые накопили в себе под миллиард записей, но при этом ни разу нигде не использовались. Наверное, это были ошибки где-то на уровне архитектуры, или когда фирмы франчайзи для нас что-то делали, а потом что-то пошло не так. Такая точечная корректировка регистров позволила сократить объем базы на 100 гигабайт – еще около 100 гигабайт ненужных данных было вычищено из базы.
- Мы провели оптимизацию кода запросов – это топ-уровень хороших разработчиков, которые не просто пишут код, но и могут разобраться в чужом и сделать это наиболее оптимально. Вручную это делать достаточно сложно, поэтому опять же, помогают сервисы, которые автоматически анализируют топ самых неэффективных запросов или запросов, которые больше всего занимают времени по базе данных. При этом любой запрос к базе данных – это, скорее всего, блокировки – взаимоблокировки или ожидание на блокировках. Мы проанализировали вручную и исправили порядка 15-20 запросов. Из самых вопиющих: запрос реестр накладных выполнялся на одних и тех же данных 220 секунд, а после оптимизации – 2 секунды, обработка печать ценников выполнялась 40 секунд, после оптимизации – 1 секунду. Таких примеров очень много, это, к сожалению, примеры непрофессионализма разработки или недостаточности знаний о работе платформы.
- Тут мы вспомнили про удаление помеченных объектов. Напомню, что когда регламентные операции не работали, это все копилось, и в результате в базе оказалось около 2-2,5 миллионов помеченных объектов, не удаляемых типовыми средствами. Поэтому длительное время мы в ночные регламентные окна все эти помеченные объекты вычищали.
Стало еще лучше, людям во многом стало комфортнее.
Помимо того, что с помощью этих точечных спецопераций мы решили проблемы архитектурно, мы еще и попросили своих коллег (пользователей, бухгалтеров) рассказать конкретные проблемы, которые их беспокоят. Например, долго открывается форма, долго проводится документ, еще что-то не устраивает.
По этим жалобам мы точечно отработали – было много моментов, связанных именно с неэффективностью написанного кода, где-то с лишними записями в регистр. Это дало очень хороший эффект.
На слайде показаны замеры APDEX на июль 2019 года. Здесь можно увидеть, что зеленого стало гораздо больше.
В самом низу видно, что в целом характеристика системы стала «хорошо» и «отлично». Но красные вкрапления остаются.
Если посмотреть по верхним пунктам, то самая важная для нас оптимизация – это документ «Реализация нефтепродуктов АЗС». Количество операций в неделю – 3503 операции, среднее время проведения – 2.9 секунды. До этого один документ проводился 15-20 секунд.
При этом видно, что плохим осталось перепроведение документов в рабочее время – кто-то запустил обработку по массовому перепроведению, и в итоге все повисло на блокировках.
Остальные неудовлетворительные пункты в этом списке – это отчеты. Мы сразу решили их поправить, но потом начали смотреть, и оказалось, что они какие-то космические – выборка данных за весь год для каждой АЗС по реализации какой-то конкретной номенклатурной позиции по дням.
Выяснилось, что из этих отчетов нужны только несколько строчек. Поэтому решили, что массово переписывать все отчеты, которые когда-то кем-то были созданы, не имеет смысла, к этому нужно применить какие-то другие подходы. В конце доклада я расскажу, что мы с этим сделали.
Четвертый этап – процессы
Запустив этот маховик, мы уже не остановились и перешли к самим бизнес-процессам.
- Мы выяснили, что бухгалтеры формируют у нас в базе около 100-150 ручных операций в месяц. Ручные операции – это когда у людей есть доступ в регистры, они туда напрямую приходят и правят там какие-то данные. Зачем и почему – с этим предстояло разобраться. Отмечу, что большинство этих ручных операций было вызвано объективными причинами, потому что не существовало инструмента, который позволил бы отредактировать данные. Но оставшиеся операции делались просто потому, что «исторически так сложилось», так было удобнее – не корректировку сделать, а просто в регистр зайти напрямую и поправить. Все это приводило к потерям производительности, но уже не системы, а людей. В основном ручными операциями пользовались бухгалтеры – они корректировали, например, только бухгалтерский регистр, при этом их абсолютно не волновало, что происходит в управленческом учете. В итоге данные в бухгалтерском регистре и регистрах управленческого учета начинали расходиться: финансисты формируют отчет, у них одни цифры, а у бухгалтеров – другие. Поскольку решают, что правильно у бухгалтеров, финансист и экономист выгружают бухгалтерские ведомости к себе в Excel, крутят данные, делают какие-то отчеты, и все это мучительно вручную сводится. Для предприятия это было колоссальной потерей производительности целых подразделений, которые вынуждены постоянно перепроверять данные, делать сверки друг с другом. Поэтому мы взяли себе на вооружение и точечно в течение месяца-двух отстреливали все ручные операции, постепенно закрывая к ним доступ. На сегодняшний день этого уже нет.
- Из этой первой проблемы вытекала вторая – финансисты не могли доверять управленческим регистрам по взаиморасчетам. Изначально, в попытках закостылить решения, которые были связаны с расхождением по регистрам, переписывались отчеты, чтобы брались данные для финансистов из бухгалтерских, а не из управленческих регистров – это все приводило к вакханалии. Поэтому мы переписали блок взаиморасчетов.
- Заодно мы переписали блок учета основных средств и материалов. Это тоже многое дало для производительности.
Традиционный автобус. Такие реально есть в Минске, они ездят на экологическом топливе, заряжаются за пару секунд на остановке и едут дальше. Не знаю, видели вы такие в Питере или нет, но штука реально крутая.
Планы на будущее
Немного про планы на будущее:
- Однозначно есть понимание, что нужно разделить базы на оперативную и аналитическую. Аналитическая база будет работать в режиме read only, в ней будут формироваться все необходимые отчеты, в том числе на 1С. Ее необходимо выделить отдельно, чтобы снять нагрузку с основной базы и более внимательно и в спокойном режиме заниматься аналитикой.
- К этой read only базе мы планируем прикрутить BI аналитику. Не секрет, что хорошая аналитика – это не сильная сторона 1С, его сильная сторона – это учет и простота его ведения. А для аналитики я бы рекомендовал другие системы: Power BI, Qlik и т.д.
- Третья задача, которую мы планируем реализовать, – это плотная связка 1С:Документооборота и ЭЦП, потому что очень много запросов приходит именно на внедрение электронного документооборота в части подписания документов электронной цифровой подписью. Изначально было представление, что это надо впихнуть куда-то в УПП. Но в итоге решили, что УПП хранит данные, там формируются проводки документов, потом из УПП формируется печатная форма необходимого документа, отправляется в 1С:Документооборот. Там она подписывается, становится юридически значимым документом, хранится и достаточно просто обеспечивается и хранение, и проверка целостности, и легальности данной подписи.
Надеюсь, мы все реализуем. И наконец-то наши пользователи будут довольны.
Вопросы
- Очень интересно собирать статистику, смотреть, анализировать перформанс монитор – это вообще очень мощная штука. Я мало знаю людей, которые умеют этим заниматься.
- Действительно, сервисы gilev.ru работают, технологический журнал анализируется, и это действительно круто. При этом мы практически на это не тратим время.
- Роман, спасибо за доклад. Вы сказали, что пришли в 2017 году, когда еще были автоматические блокировки и так далее. А вы вообще УПП не обновляли никогда? Где регламентированная отчетность? Она в другой базе?
- Белорусский рынок и белорусский 1С сильно отличается от российского. Надо понимать, что для Беларуси нет ни одной реально написанной конфигурации. Это все адаптация. Например, в России вышла УПП с российским учетом, в Беларуси какие-то компании ее адаптируют. Но представительства фирмы «1С» у нас нет, поэтому и регламентных типовых обновлений практически нет. Не говоря про то, что ИТС вообще не работает. ИТС нужен только для обновления платформы.
- Понятно. Еще один маленький вопрос. У вас был road map – обновление платформы с 8.1 на 8.2, потом включили управляемые блокировки, потом перешли на 8.3. Это только обновили платформу или все-таки еще и режим совместимости конфигурации поменяли?
- Я уже говорил, что делали обновление платформ со снятием режима совместимости. Мы его полностью выключали. Сейчас у нас конфигурация УПП работает на платформе 8.3.10 без режима совместимости в принципе.
- Вопрос по теме доклада «Замеры APDEX против ощущений бухгалтеров» – как вы построили шкалу APDEX, если у вас, исходя из всего доклада, бухгалтера все равно были недовольны. Как вы выделили нижнюю и верхнюю границы?
- При любых работах, связанных с оптимизацией производительности, какие-то метрики должны быть обязательно – APDEX либо любая другая. Потому что в процессе очень сложно отличить, изменилось вообще что-то, стало лучше что-то или нет. Да, бухгалтера были недовольны. Но как собирались метрики? Есть типовой набор, когда в метрики добавляются все документы и на них ставятся счетчики на проведение документа. Если я не ошибаюсь, эталон для проведения документа – 1-2 секунды в зависимости от нагруженности базы. Дополнительно мы провели опрос всех пользователей, бухгалтеров, что им еще не нравится. В опроснике мы спросили, за сколько времени определенный документ должен проводиться. По этим значениям мы настроили APDEX, выставили эталонное время и дальше по нему уже работали.
- Получается, не было такого, что вам бухгалтера всегда говорили, что все плохо?!
- Они всегда говорили, что все плохо, независимо от того, что показывает APDEX. Но нам важно было не бухгалтерам что-то доказать, нам важно было показать руководству состояние системы до и после изменений без субъективных оценок. Мы внедрили независимого свидетеля этой работы, и ни я не могу повлиять на эту методику, ни пользователи не могут на нее повлиять, ни даже наши разработчики этого не могут. Стоит добавить, что в процессе трансформации системы из состояния «А» в состояние «Б» были человеческие потери. У меня в ИТ-отделе были потери, с некоторыми людьми пришлось расставаться. С некоторыми бухгалтерами пришлось расстаться – особо критично настроенными. Это неизбежно. Но для компании это был положительный момент. Я ещё раз повторю – нашей задачей не было сделать всех бухгалтеров довольными, мы должны были сделать так, чтобы бизнес перестал терять время на медленной работе систем. Именно об этом мы договаривались с генеральным директором. Поэтому степень удовлетворенности пользователей – это важно, но все-таки более важно объективное состояние системы.
- Но у вас тема доклада про APDEX, который касается удовлетворенности пользователей. А получается, что в данном случае это, скорее, удовлетворенность бизнеса.
- APDEX показал отличную удовлетворенность. А то, что показывает APDEX, – это не то, что думает бухгалтер. Например, если бухгалтер согласился, что проведение документа за 5 секунд его устроит, сама операция занимает 2 секунды, но бухгалтер все равно недоволен, значит, он недоволен чем-то еще – стулом, компьютером, кабинетом. Но это уже не совсем про информационные системы.
- Хочу уточнить такой момент: опрос пользователей, который вы делали на APDEX, проводился один раз, и потом вы по нему работали? Либо такие опросы проводились на постоянной основе?
- Когда мы делали опрос, откликнулись, наверное, только 5% всех пользователей, большинство не дали конкретных ответов. Поэтому мы сознательно добавили в мониторинг APDEX по умолчанию все документы, которые есть в информационной системе. И еще добавили открытие форм, какие-то отчеты, на которые нам указали. У нас есть тикетная система, и если туда прилетает заявка о том, что у кого-то что-то медленно работает, мы этот объект добавляем в APDEX. Мониторинг работает постоянно – мы все его объекты для себя анализируем, а если еще и приходит запрос от пользователя, то мы точечно смотрим, что не так. Бывают моменты, когда выплывает что-то, что мешает нормальной работе системы.
****************
Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.
