Дорогие читатели!

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

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

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

IE: Какую из проблем, связанных с системой автоматизации финансово-хозяйственной деятельности предприятия, Вы считаете самой тяжелой?

Аноним: Самая острая проблема - это переход на новую версию системы. Активно расхваливаемая «полная совместимость версий» на самом деле миф. Да, на "игрушечных" модельных БД все действительно проходит "на ура", но реальная жизнь весьма далека от игрушечной. Что надо сделать, прежде чем перейти на новую версию? «Ощупать» всю систему сверху донизу. Потому что привычные схемы, исправно работавшие раньше, в новой версии могут и не заработать. Однако протестировать абсолютно все, что есть в системе, нереально; по крайней мере, у нас это не получается. Мое мнение: переходить на новую версию системы без полного пакета техподдержки нельзя.

IE: Это связано с изменениями, которые вносятся в новую версию?

А.: Не только, причины могут быть разные. Есть «дырки», упущенные вследствие постоянной гонки. Мы не раз с этим сталкивались, "карусель патчей" (программных заплаток) — одно из неизбежных зол. Первый патч закрывает дыру, второй, закрывая следующую, возвращает первую. У нас даже выработалось правило: пока для новой версии не выйдет второй крупный патч по оперативному управлению, мы на нее не переходим. Ни в коем случае! По опыту мы знаем, что переход оправдан не раньше, чем через год после выхода новой версии. И вообще, мы стараемся держаться старой привычной версии до тех пор, пока она официально не снята с "фирменной" техподдержки, пока она продолжает обновляться "мелкими мазками" в соответствии с изменяющимся законодательством и прочими реалиями жизни. Руководство это правило не утверждало, но мы ему следуем очень твердо.

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

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

IE: Недокументированные функции - это все-таки не совсем корректный пример...

А.: Есть и другие. Скажем, однажды мы переводили несколько баз данных на новый релиз системы. Все перешли нормально, а в последней по непонятной причине стали "рушиться" настройки зарплаты. Еще в одном случае при таком переходе потерялась информация по аналитическому бухгалтерскому учету — не вся, частично (но это, кстати, только хуже, потому что не сразу обнаруживается). Отработали некоторое время после перехода и вдруг нарвались на ошибки в бухгалтерских отчетах. Такие вещи уже привычны, мы точно знаем, что где-нибудь что-нибудь обязательно "слетит". Тогда мы берем старую базу данных и все восстанавливаем. Мы храним все старые БД до тех пор, пока эти данные нужны. Опыт показывает, что двух лет мало, мы их храним не менее пяти лет.

Впрочем, надо отдать должное разработчикам — не все так уж плохо. В целом настройки процессов и логистики сохраняются при переходе на новый релиз или новую версию. Хотя в некоторых местах системы сам производитель рекомендует нам вручную пересоздать настройки при переходе, и зачастую приходится предыдущие настройки "фотографировать" с экрана. В принципе это не слишком трудно, но важен сам факт! Бывают и другие довольно неприятные «фокусы».

IE: А поддержка поставщика разве не помогает в этих случаях?

А.: Помогает, но за техподдержку ведь нужно платить. Вопросы решаются, дело только в сроках, а тут бывает по-разному. По мелочам мы, как правило, в техподдержку не обращаемся, разбираемся самостоятельно. Но если дело затягивается, обращаемся (хотя бы для того, чтобы защититься от собственного руководства). И вот, бывает, в техподдержку поступает вопрос, от которого эксперты поставщика приходят в ужас — они просто не верят, что такое бывает. Пару раз случалось такое, что, признаться, и сам бы не поверил, если бы не видел своими глазами.

Конечно, такие экстремальные варианты — редкость. Многие проблемы оказываются экспертам знакомы, и тогда они быстро подсказывают, что делать. Бывает, что причина и в нашей некомпетентности. Кто-то из администраторов в суматохе решения, например, одной из описанных выше проблем изменил настройку, не имевшую никакого отношения к делу, в результате чего некоторые начисления у части сотрудников при расчете зарплаты стали обнуляться, причем только у сотрудников, которые работали по нестандартному графику. Естественно, и мы, и эксперты техподдержки стали смотреть графики работы, а там были дополнительные проблемы, которые ситуацию только запутали. Неделю весь отдел работал в авральном режиме, думали даже вернуться к старой версии базы, потеряв при этом больше недели работы операторов. Решение мы нашли сами, эксперты техподдержки о возможности такого прокола даже не подумали. Но стоит ли в этом винить техподдержку?

Это обычное минное поле. Где, когда и под какую ногу подвернется следующая растяжка, заранее не угадаешь. Отчасти это проблемы поставщика, отчасти наши. Не стану никому отдавать "пальму первенства", поделю 50 на 50. Чтобы избежать таких проколов с нашей стороны, надо вводить очень жесткие рамки, но любое ужесточение правил приводит к потере гибкости.

IE: Если с настройками встречаются такие проблемы при конвертации, то что же говорить о доработке системы?

А.: Конечно, типовую стандартную конфигурацию дешевле поддерживать. Но на практике такого не бывает. На большинстве рабочих мест у нас установлена практически стандартная конфигурация, но 10—15% функционала нужно «подкручивать». Разумеется, структуру данных мы не меняем, индексы не добавляем. Но в части сопряжения данной системы с другими выходить за рамки стандартных возможностей интерфейсов приходится часто. Если нужен интерфейс на уровне базы данных, чтобы забрать данные из одной БД и положить в другую, то тут постоянно встает проблема выбора: посадить операторов, которые будут вручную все переводить, либо эти функции программировать. Но когда компания перейдет на следующую версию системы, все запрограммированное придется переписывать. Вот и приходится держать штат программистов.

Есть еще вариант изыскивать какие-нибудь недекларируемые механизмы внутри системы. Хотя и среди стандартных "строительных кубиков", предоставляемых системой, если копнуть поглубже, можно найти немало интересных возможностей. Правда, общее правило остается в силе — чем сложнее «наворот», тем больше проблем будет в будущем с обновлением. Хотя бы в смысле времени, которое придется потратить на тестирование. Я придерживаюсь следующего правила: примерно треть подобных задач возлагаю на оператора, не автоматизирую. Зачем загружать программистов автоматизацией задачи, на которую у оператора уходит 10—15 мин в день? Вручную это сделать надежнее.

IE: Может быть, тогда проще совсем обойтись без информационной системы, скажем, взять 10 бухгалтеров со счетами?

А.: Нет, нельзя. Без подобной системы просто невозможно вести бизнес. Правда, уменьшая риск человеческой ошибки, система нередко добавляет свои собственные риски, вносит новые ошибки. Если человеку периодически приходится повторять одну и ту же работу из-за постоянно возникающих ошибок, он напрягается, внимательнее проходит этот участок, "вычищает" его и фиксирует на бумаге, и это дает гарантию, что здесь ошибки больше не будет. Однако когда то же самое скрывается за интерфейсами учетной системы, подобной гарантии нет, потому что сама система может вносить ошибку, а человек просто не способен охватить единым взглядом весь наработанный объем данных. В результате остается непонятно, все у тебя в порядке или нет, поскольку не известны схемы преобразования, конкретные алгоритмы закрыты.

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