Лучшее — враг хорошего
Автор
Андрей Федоров
В очередной раз подтвердилось правило, выработанное еще с Microsoft: не запускать продукт в работу, пока не вышел первый Service Pack
В докризисную пору многие компании стремительно развивались, что позволило им, несмотря на последующие падение и стагнацию, сохранить пусть и небольшой положительный тренд. О крупных, затратных проектах речь, конечно, не идет, но поддерживать то, что уже было создано, все же удается. Однако, согласитесь, это довольно тоскливая активность.
Обращаться к чему-то новому в сегодняшних условиях, на мой взгляд, экономически нецелесообразно. Функционирует все вроде бы неплохо, но вот динамика роста продаж такова, что практическое использование какого-то иного продукта не окупится спустя и десяток лет. Хотя при политическом решении могут и SAP заставить внедрить, даже если он вообще никогда не окупится. На таком фоне проекты, выполненные у нас в компании, — это попытки относительно недорого перейти на очередной виток развития за счет применения новых версий корпоративного ПО.
DocsVision 4.X
Хотелось бы остановиться на одном весьма показательном проекте — внедрении электронного документооборота. Итог его видится достаточно спорным, поскольку работы выполнялись при минимальном финансировании (что называется, по остаточному принципу). Дело происходило в 2009 году, и это была скорее некая проба пера для продуктов такого рода. Ведь прежде у нас использовались главным образом сильно кастомизированные решения, разработанные собственными силами и заточенные для удобства пользователей так, чтобы выжать максимальный эффект. Практика эта довольно затратная, но при росте экономики с лихвой окупается за счет увеличения производительности труда.
Для оптимизации работы компании в изменившихся условиях были инициированы значительные изменения организационного плана, что потребовало упорядочения процесса согласования договоров. Обозрев рынок продуктов, остановились на DocsVision 4.X. В частности, потому, что на тот момент существовала типовая конфигурация данного решения, примерно на 85% удовлетворявшая наши запросы. Кроме того, платформа была написана на .NET, что позволяло относительно легко интегрировать продукт с решениями, разработанными внутри компании.
Вот тут-то и была совершена одна довольно типичная ошибка. Не располагая достаточными внутренними ресурсами для изучения и поддержки продукта, мы вознамерились отдать его доработку на откуп аутсорсеру. Причем наивно полагая при этом, что, раз платформа универсальная и бизнес-процесс «рисуется» соответствующими функциональными блоками, то привлеченная сторона сможет относительно легко поддерживать и развивать это хозяйство.
Как доказывает практика, чтобы эффективно работать с аутсорсерами, нужно знать предмет не намного хуже их, не до деталей, но все-же достаточно глубоко. Когда в дальнейшем начались проблемы с работой системы, мне пришлось погрузиться в изучение деталей, и блок-схема одного из основных бизнес-процессов, отвечающих за согласование, вызвала тихий ужас. Такого мне видеть не приходилось: множество связей, масса набросанных функциональных блоков, в том числе с написанными на C# обработками, и прочее и прочее.
На мой взгляд, код, написанный на C#, выглядит куда более доходчиво, есть развитой инструментарий, ясно, как его отлаживать. В случае же с платформой регулярно натыкаешься на какие-то моменты, когда отладка выглядит очень непросто. Судя по всему, решение «Согласование договоров» было выполнено для какой-то крупной организации и потом из него сделали «типовую» конфигурацию, обрезав лишний функционал. Причем весьма грубовато: осталось немало ненужного, что кардинально ухудшило читаемость бизнес-процесса. Таким образом, продвигаемый маркетологами производителей подход, что любой бизнес-процесс может быть «нарисован» бизнес-аналитиком, не смыслящим в программировании, судя по всему, все же неблизкая перспектива. Нарисовать-то можно, но вот что потом с этим чудом делать...
Перед запуском нам требовалось несколько изменить типовой бизнес-процесс «Согласования договоров». Компания-аутсорсер мужественно пыталась встроить в вышеописанное монструозное содержимое несколько заплаток, чтобы получилось необходимое нам решение. Задача осложнялась тем, что параллельно в нашей компании шли организационные изменения, это приводило к корректировке и самого бизнес-процесса согласования, и его реализации в DocsVision.
В конце концов решение заработало так, как нужно (точнее, нам так думалось на этапе тестирования), и мы запустили его в опытную эксплуатацию. Перед этим два сотрудника отдела прошли обучение, чтобы сопровождать систему.
Итак, DocsVision пахал, но не особо стабильно. То и дело возникали глюки с ActiveX-компонентом, реализующим интерфейс пользователя в браузере, а бизнес-процессы периодически подвисали, их приходилось регулярно перегружать и т. д. Это вызывало у сотрудников компании негативную реакцию, тем более что с увеличением количества документов в системе нестабильность в работе только росла.
А спустя некоторое время DocsVision полностью прекратил обновление типовой конфигурации «Согласование договоров». Не знаю, с чем это было связано: то ли разработчики признали, что не могут справиться с нестабильностью системы, то ли продажи типовой конфигурации оказались незначительными. Насколько помню, за все время вышла разве что пара-тройка апдейтов конфигурации при обновлении версии платформы (видимо, чтобы вообще работало), которые не привели к кардинальному улучшению. При возникновении проблем с работой начинался типичный футбол: DocsVision кивал на изменения конфигурации, мол, поэтому они не могут отвечать за ее работоспособность, а аутсорсер разводил руками, мол, типовая конфигурация столь сложна, что понять, в каком месте бизнес-процесс отрабатывает некорректно, невозможно (читай: дорого).
Аутсорсер предложил переписать бизнес-процесс под нас, максимально задействуя функционал платформы. Причем затраты обещали быть минимальными, поскольку функциональные требования можно было взять с работающей системы и внести корректировки лишь в тех местах, где они не очень хорошо ложились на наши процессы.
DocsVision 5.X
Вскоре борьба с глюками DocsVision 4.5 стала отнимать слишком много времени у ИТ-отдела. По сути, система умирала, но как ее реанимировать — не знал никто. Аутсорсер высказал довольно интересное по стоимости предложение: перейти на новую версию системы – DocsVision 5.1. В итоге решили временно начать согласование старым способом, через e-mail. В очередной раз я познал мудрость выражения «нет ничего более постоянного, чем временное».
В силу ряда причин обсуждение «апгрейда» DocsVision с 4.5 на 5.1 затянулось надолго. Параллельно рассматривался переход на «1С Документооборот», и сейчас представляется, что этот вариант был бы, возможно, не хуже. Хотя пока не внедришь — не узнаешь. Одно скажу: если согласование какой-то закупки или внедрения продукта идет из рук вон плохо, то и дело возникают препятствия, похоже, — это сигнал «свыше» задуматься, стоит ли вообще этим заниматься. Как правило, после такого «тяжелого» согласования продукт живет недолго или несчастливо. Как ни парадоксально, стоит уделять таким намекам внимание, иногда в ущерб логике.
В общем, решение о переходе приняли со скрипом. Одновременно были согласованы функциональные требования к системе, но детальное ТЗ не прописывали. Акцент следовало сделать на типовом функционале платформы, чтобы сократить стоимость разработки и минимизировать затраты при переходе на новые версии.
По обыкновению, разработка решения заняла больше времени, чем планировалось. Аутсорсер не имел достаточного опыта создания и развертывания решений на 5.1, поскольку сама платформа относительно новая, и, естественно, по ходу реализации возникло немало сложностей. В том числе ошибкой была установка серверной части на только что вышедшей версии продукта 5.2.
Производитель утверждал, что она более стабильна, чем 5.1, однако в очередной раз подтвердилось правило, выработанное еще с Microsoft: не запускать продукт в работу, пока не вышел первый Service Pack. В общем, после того как была потрачена масса времени на запуск разработанной конфигурации на 5.2, решили развернуть параллельно сервер под 5.1. Дело пошло живее, но время было упущено.
В старой версии 4.5 у нас неоднократно возникали трудности при развертывании клиентской части DocsVision на десктопы и рабочие места. Относительно спокойно все проходило только в случае, если пользователь работает с правами администратора. Поскольку наши сотрудники работают с правами обычного пользователя, при установке клиентской части развертывание выполнялось с помощью MS Configuration Manager. На терминальные серверы установка велась вручную из-под учетной записи администратора. Правда, учитывались рекомендации DocsVision, однако это не очень помогало. Клиент вставал корректно, но при открытии DocsVision Navigator или карточки задания вываливались ошибки, причем чаще всего диалог был .NET framework, то есть сразу идентифицировать проблему было затруднительно. Благо, техподдержка DocsVision подсобила патчами, да и аутсорсер реагировал достаточно оперативно.
Инсталлятор клиентской части DocsVision требует перезагрузки. Подобную процедуру несложно провести для десктопов, но в случае с терминальными серверами, на которых трудится несколько десятков человек, это вызывает проблемы, так как выполнить перезагрузку можно только после окончания рабочего дня либо в обеденный перерыв, да и то не всегда. Этот фактор затягивает сроки решения проблем. Уже десяток лет проблема с необходимостью перезагрузки после установки терзает умы ИТ специалистов, но масса ПО по-прежнему недалеко ушла в этом плане. Как будто не ведают, что софт может устанавливаться в терминальных средах. Словом, какие-то детские болезни так никак и не лечатся.
Итак, времени на развертывание клиентов ушло немало, причем проблема со стабильным запуском до сих пор не решена. Такое ощущение, будто в гонке за покупателя (предложение новых версий продукта) производители настолько увеличили скорость разработки и сократили тестирование, что «сложность продукта превысила способности разработчиков». Хотя, несомненно, общему развалу качества способствует и регулярный выпуск новых операционных систем, .NET framework, баз данных и пр. Протестировать продукт на всевозможных сочетаниях платформ становится крайне непростой задачей.
Отчасти из-за проблем с развертыванием клиентов многие производители уходят в сторону веб-решений. Почему-то в DocsVision продолжают держать акцент на развитии Windows GUI-интерфейса и как-то не особо развивают «легкий клиент» — веб-продукт, не требующий установки. На вопрос, почему бы нам не запустить решение под «легким клиентом», если не удается быстро разобраться с полноценным, аутсорсер ответил, а техподдержка DocsVision подтвердила, что кастомизированные карточки, используемые в созданном для нас решении, работать не будут. Кстати, сам «легкий клиент» продается как отдельное решение, которым не комплектуется даже расширенная редакция DocsVision, хотя нынче веб-интерфейс уже становится основным. Создается впечатление, что DocsVision застрял где-то в прошлом, да еще и денег на каждой такой мелочовке хочет «срубить».
Есть странные моменты в реализации базовых вещей. Например, уникальность контрагента в справочнике проверяется по его наименованию, хотя даже в одном регионе может быть несколько компаний с одинаковым названием. Именно поэтому уже вошло в правило проверять российские предприятия по ИНН. Техподержка DocsVision ответила, что отключить проверку по наименованию нельзя, а реализация проверки по ИНН будет стоить отдельных денег. Получается, мало того, что некорректно с точки зрения российского законодательства, так за выправление недочетов ещё и доплатить надо.
***
Похоже, в софтовой индустрии продолжается кризис идей. Вроде как выпускаются новые версии продуктов, вносятся некие улучшения, при этом далеко не всегда очевидны обещанные преимущества, в частности заметный прирост производительности или сокращение стоимости сопровождения. Притом что задумки, которые стоило было бы реализовать, вроде как есть. Словом, движение присутствует, но куда? Основная цель — заработать денег – прослеживается четко, а вот какой навар получит потребитель, ясно далеко не всегда.
Опубликовано 24.12.2013