Половинчатое решение с отрицательным результатом
Половинчатое решение с отрицательным результатом
Итак, IT-отделу предстояло постепенно создать всю IT-инфраструктуру (корпоративную систему) заново. Прежде всего требовалось разнести веб-витрину и бэк-офис, чтобы они не тормозили друг друга. Учитывая тот факт, что руководство ожидало каких-то результатов в более или менее обозримом будущем, в IT-отделе решили попробовать использовать для бэк-офиса одну из готовых универсальных разработок, которую нужно было просто адаптировать под имеющиеся задачи.
В результате определили, что для веб-витрины будет разрабатываться новый механизм на технологии Java Server Pages[6] и веб-сервере Apache[7] под управлением операционной системы FreeBSD,[8] а для бэк-офисной системы предполагался микс готового решения и собственных модулей. В качестве готового решения выбрали продукт Navison Axapta.[9]
Navison Axapta была на тот момент достаточно инновационной системой с классическим набором функций и продуманным интерфейсом. Она подходила для решения определенных бизнес-задач и использовалась в некоторых европейских фирмах. В России у Navison Axapta существовал партнер: фирма Columbus IT Partner, которая осуществляла локализацию продукта и консультирование по вопросам внедрения.
Однако, провозившись несколько месяцев с адаптацией Axapta под бизнес-процессы OZON.ru, в IT-отделе с большим сожалением пришли к выводу, что данный продукт (да и, скорее всего, другие аналоги) не годится для решения имеющихся задач. Ситуация получалась странная. С одной стороны, в Axapta была заложена вся необходимая функциональность для построения различных бизнес-процессов, но с другой – при попытке реализации конкретных озоновских задач специалисты неизбежно натыкались на необходимость очень серьезной доработки соответствующего функционала, то есть фактически написания его заново.
В Axapta разработка собственных модулей велась на встроенном языке Morph, представляющем собой весьма неудобную в использовании помесь С++ и Transact SQL, и в отделе в конце концов пришли к выводу, что в этом нет никакого смысла. Axapta годилась бы для решения поставленных задач только в том случае, если бы ее механизмы требовали всего лишь адаптации и небольшой доработки. Однако практика показала, что в любом случае почти все придется разрабатывать самим, а в Axapta это было и неудобно, и дорого, так как требовало привлечения дорогостоящих консультантов.
В результате после неоднократных совещаний с руководством в июне 2001 года было принято очень болезненное, но совершенно необходимое решение: внедрение Axapta забыть как страшный сон, а IT-отдел начнет собственную разработку соответствующих систем, не надеясь уже ни на какие готовые решения. Да, примерно тридцать тысяч долларов, потраченных на попытку внедрения Axapta, вылетели в трубу. Однако отрицательный результат, как тогда решили, – тоже результат. Благодаря ему в OZON.ru убедились в том, что готовые решения в данном случае не подходят, поэтому свой бэк-офис нужно писать самим.
Данный текст является ознакомительным фрагментом.