Написать данную статью меня побудил тот факт, что в течении 2 лет мне пришлось поработать консультантом ERP-системы Microsoft Dynamics AX (далее АХ) хотя до этого внедрял 1С в различных ролях, руководил комплексными проектами по системной интеграции, постановке и автоматизации управленческого учета и бюджетирования, а так же работал на топ-менеджерских должностях в реальном бизнесе. То есть данная статья это взгляд сугубо практический.
Практически всю жизнь я занимался внедрением решений, основанных на платформе 1С Предприятие. В начале как программист, затем все больше мигрировал в область консалтинга. Последнее время работал в качестве проектного менеджера и консультанта по внедрению в одном лице. В процессе изучения АХ я не мог не отмечать различия, схожести, сильные и слабые стороны систем. И вот, чтобы не растерять свежие впечатления решил зафиксировать их и поделиться.
Прежде всего хочу уточнить, что в случае АХ работал с версией AX 2012 R3, в основном с российской локализацией и больше всего с финансовым модулем и немного с логистикой. Что касается 1С, то я немного застал версию 6.0, плотно внедрял 7.7, активно внедряю 8.2 и 8.3.
Безусловно, в данной статье я не претендую ни на абсолютную истину, ни на полную объективность. Скорее это просто попытка поделиться своими впечатлениями и сделать сравнительный анализ двух систем. Если мои мысли будут кому-то полезными и интересными – буду рад. Если кому-то есть что добавить или поправить меня – открыт для диалога.
Общие моменты.
Безусловно, АХ система очень мощная, функционально насыщенная и сложная. И изучить её за 2 года, конечно же, нельзя в полном объеме. Однако, имея 20-летний опыт работы в области автоматизации систем управления, могу с уверенностью сказать, что, имея глубокие практические знания и понимание бизнес-процессов реального бизнеса, можно лучше понять многие инструменты, подходы, приемы и решения, применяемые в АХ.
Прежде всего, хочется отметить, что у многих сложилось ошибочное мнение (особенно этим грешат специалисты, давно работающие с АХ) о том, что АХ это полноценная и мощная ERP-система для крупных предприятий, а 1С простенькая заурядная бухгалтерская программка, распространенная и применимая только на территориях бывшего СССР. Если у кого-то есть в голове подобные представления об устройстве мира, то можно смело сказать, что они давно устарели. Просто АХ всегда была таковой, а 1С достаточно активно и динамично прошла путь от простенькой бухгалтерской программы до полноценной масштабируемой ЕРП-системы масштаба крупного предприятия.
Не хотелось бы погрязнуть в методологических дискуссиях по поводу того, является ли 1С «полноценной» ЕРП системой или нет. Я в таких вопросах предпочитаю не занудствовать, а подходить к вопросу индивидуально – с точки зрения того, подходит ли система под конкретное предприятие и для решения каких задач она используется. Потому что термин ERP это всего лишь (дословно) «система планирования ресурсов предприятия», а все остальное это просто смысл (чаще всего очень субъективный) вкладываемый в данный термин различными людьми.
Интернациональные возможности. Слои. Обновления.
Что в АХ сразу же бросается в глаза после 1С это изначальная заточенность на международные компании и конечно объектно-ориентированный язык разработки. Про объектно-ориентированное программирование (далее ООП) в АХ я расскажу отдельно, а сейчас остановлюсь на интернациональных особенностях систем.
К однозначным сильным сторонам АХ я бы отнес тот факт, что в ней сразу же содержится весь функционал и все возможности системы. Поясню на примере что имеется в виду. Когда вы принимаете решение начать работать в 1С, то вам необходимо выбрать конфигурацию, т.е. прикладное решение, реализованное с помощью объектов 1С (справочники, документы, отчеты) и на языке 1С. Конфигураций существует огромное множество. Основная их классификация происходит с точки зрения отраслевого назначения (например, для розничной торговли, для производства, для управления больницей, школой и т.п.) и национальных законодательных требований. К примеру, вы работаете в Украине и у вас розничный бизнес. Тогда вам подойдет, например, конфигурация «1С Розница для Украины». Или у вас производство в Казахстане, тогда «Управление производственным предприятием для Казахстана». Названия условны, но принцип я думаю понятен.
Но если в будущем, бизнес расширится, и вы займетесь производством, то вы станете перед нелегким выбором: начать вести производство в отдельной конфигурации (базе) или же переходить на интегрированную конфигурацию «Розница + Производство» и работать в единой базе. Каждый из вариантов сопряжен с затратами времени, денег, сил. В первом случае вы обрекаете себя на постоянную синхронизацию двух систем (со всеми вытекающими отсюда последствиями), во втором – придется опять переносить остатки и исторические данные (либо смириться с тем, что в новой системе не будет исторических данных, и чтобы их посмотреть придется держать старую систему и периодически в неё заходить).
Так вот в АХ такой проблемы нет. Если вы принимаете решение начать работать в АХ, то вы получите весь функционал – все модули, и все локализации (функционал под требования законов разных стран) сразу «в одном флаконе». Побочным эффектом данного факта является то, что система тяжеловата – десятки тысяч таблиц, отчетов и т.п. Большинство из которых вам скорее всего никогда не понадобятся. Но зато после разворачивания системы вы можете не беспокоиться о том, что у вас открывается предприятие, например, во Франции, хотя до этого весь бизнес располагался в Украине. Вы просто добавляете новое юридическое лицо и указывает его location (местоположение) – Франция. При этом во всем, что будет касаться этого юридического лица будет подтянут региональный функциональный слой кода. То есть все требования французского законодательства, всех их региональные особенности и требования будут автоматически применяться для данного юридического лица и всего что с ним связано.
Т.е. весь насыщенный функционал АХ организован таким образом, что в различных случаях задействуется различная функциональность. Пакеты функциональности называются слоями. Примеры слоев: системный SYS – используется всегда и всеми, LOS – слой функционала для конкретной страны, USR – пользовательские доработки, т.е. модификации, сделанные под конкретного пользователя или клиента. Это очень удобно, так как если происходят глобальные изменения, то обновляется только SYS слой, если обновления затрагивают только локализацию конкретной страны, то LOS слой. При этом изменения в USR слое можно удалить при переносе решения к новому клиенту. Подробнее про слои можно почитать хотя бы вот тут (первая попавшаяся в гугле ссылка).
1С так же заметно двигается в этом направлении. С недавних пор в 1С появился механизм расширений (подробно можно почитать по ссылке). Когда я почитал его описание, то сразу понял к чему это и зачем. Проблема обновления типовых конфигураций (т.е. тиражируемых решений) существовала всегда. И именно из-за отсутствия понятия слоев в платформе.
Естественно, что в требованиях разных компаний и пользователей всегда существовали общие моменты (бухгалтерский учет, учет валюты, правила розничной торговли и многое другое), но в тоже время каждый клиент неизбежно хочет что-то подстроить под себя. Хорошо если это можно сделать гибкими средствами опциональной параметрической настройки (зашел куда надо, включил галочку или заполнил нужное поле и всё работает), но так можно сделать далеко не всегда. Гибкость системы не бесконечна. Поэтому приходится «допиливать» тиражируемое решение под конкретного клиента. Но в то же самое время тиражируемое решение тоже не стоит на месте и развивается. В нем исправляют старые ошибки (плодя новые J ) развивают функционал. И неизбежно наступает момент, когда нужно сделать мучительно-сложный выбор – продолжать развивать свою систему в отрыве от тиражируемого решения (теряя все новые возможности и исправления ошибок), либо стараться поддерживать возможность все-таки обновиться до новой версии тиражного решения. В 1С это всегда было сложностью, с которой постепенно боролись. Сначала появилась возможность выборочного обновления объектов, потом – расширения. Но решение по слоям мне нравится больше. По сути, я думаю в 1С механизм расширений придет к тем же слоям. Потому что даже сейчас в примерах использования расширений просматривается механизм разделения функционала на обновляемый с типовым решением и индивидуальный (для региона, отрасли, конкретного клиента).
Универсальные гибкие настройки.
Еще что меня порадовало в АХ это очень глубокая методологическая проработка и системность в подходе к проектированию системы. Все-таки братья Дамгаарды очень основательно подошли к проектированию системы Concord Finance, которая была прообразом АХ в далеком 1986 (кратко, но ёмко почитать о истории АХ можно по ссылке). Потому что просто невозможно не восхищаться некоторыми решениям с точки зрения лаконичности и универсальности. К примеру, система расчета налогов содержит по большому счету десяток-полтора таблиц, и, по сути, одну главную форму настроек, но она позволяет без модификации (программирования) настроить любые налоги и удержания любых стран мира. Точно такая же гибкая и универсальная система настройки хранения и использования налоговых регистрационных кодов – ИНН, ЕДРПОУ, КОАТУУ и подобных им. Что интересно, несмотря на длительную историю и неоднократные перепродажи системы, базовые вещи новые собственники (тот же Майкрософт) не решаются трогать. И правильно, кстати делают: работает? Не трогай! J
Что же в этом плане у 1С. Она тоже не отстает. Кстати, слышал много мнению по поводу того, кто у кого «передрал»/подсмотрел решения. Мне кажется, что это не столь важно уже. К тому же многие решения что называется лежали на поверхности и прийти к ним могли и параллельно. Та же трехзвенная архитектура, например. Я сталкивался с примерами гибкого функционала, который в 1С существует где-то с 2008 года (выход версии 8.2), но который появился в АХ только в версии 2012 (где-то 2014 год), так и наоборот: в АХ решение существует давно, а в 1С только недавно появилось (те же слои и расширения).
В качестве любопытного пример кому интересно можете посмотреть 2 видео. Первое видео это мое выступление с рассказом о механизме АХ “Product configuration model”, который представляет собой гибкий конфигуратор продукта - ссылка на видео. Второе видео это описанием механизма работы свойств номенклатуры в конфигурации «1С Управление предприятием ERP 2.0» на канале Андрея Мироненко ссылка на видео. Что называется – найдите 10 отличий J
Кто за всё это платит.
С другой стороны, необходимо понимать, что универсальность и гибкость — это не всегда плюс системы. Тут, как во всём, нужно знать меру. Я разделяю подход разумной достаточности. Мне кажется, что во многих случаях красивые и гибкие механизмы АХ остаются непонятыми и, соответственно, не востребованными не то, что пользователями, а даже начинающими консультантами, которые не хотят глубок вникать и «заморачиваться».
С другой стороны, слишком большая гибкость и универсальность так же приводит к тому, что для полного и качественного изучения функциональных возможностей даже одного модуля консультантам требуются долгие годы. Что приводит к дефициту хороших опытных специалистов по системе и естественно к высокой их стоимости. Потребитель не всегда готов платить за это. В конце концов ему нужно работающее решение с приемлемой совокупной стоимость владения. АХ в этом плане существенно проигрывает в среднем сегменте. Потому что компания должна иметь очень серьезные финансовые возможности чтобы выложить сначала сотни тысяч- миллионы долларов за лицензии и еще столько за внедрение. Плюс потом приходится содержать либо наемных штатных консультантов и программистов, либо периодически оплачивать далеко не дешевые услуги внешних специалистов.
В 1С ситуация в чем-то обратная. 1С в свое время получила большую популярность за счет простоты, дешевизны и хорошо налаженной сети франчайзи-внедренцев. Обратной стороной дешевизны всегда было низкое качество и 1С в этом плане не является исключением. Типовые конфигурации от 1С часто сопровождались нареканиями пользователей о том, что это скорее примеры реализации возможностей платформы, чем готовые законченные качественные решения. Мне даже иногда кажется, что множественные мелкие недоработки в типовых конфигурациях, это осознанная политика 1С с целью «дать хлеб» франчайзи-внедренцам. Хотя в последние лет 5 ситуация меняется. Внедренцы 1С уже доросли до полноценного отделения функциональной роли консультанта в процессе внедрения, и сама 1С сертифицирует консультантов по своим типовым конфигурациям. Мне кажется, что это очень правильный подход, от которого выиграет и качество конфигураций, и качество внедрений, и удовлетворенность пользователей. Но это процесс конечно не быстрый. Должно пройти достаточно много времени чтобы сформировалась армия достаточно опытных и квалифицированных консультантов умеющих грамотно внедрять сложные и гибкие решения.
Пользовательская документация и сообщения о ошибках.
Что касается дружественности интерфейса, полноты и качества описания функциональных возможностей, то меня тут ждало жестокое разочарование после 1С. Тот факт, что продаваемое потребителю решение должно содержать полное, качественное и исчерпывающее описание функциональных возможностей казалось мне само собой разумеющимся фактом. Но, к великому сожалению, в процессе изучения АХ я столкнулся с тем, что полного и законченного описания просто не существует. Конечно, есть ресурсы самого Майкрософт вроде https://technet.microsoft.com/ru-ru/ Но! Там описан в основном общий функционал и очень мало информации о локализациях. Да и общие описания часто слабые и по полноте, и по качеству (часто приходится довольствоваться машинным переводом).
Конечно, причины для такой ситуации есть. Функционала очень много, он слишком быстро развивается и поддержание качественной документации на такой количество языков удовольствием слишком дорогое даже для Майкрософта. Но я считаю, что это не оправдание. Продаете дорогую систему в больших количествах – будьте добры обеспечьте пользователей качественным описанием.
Вторая ложка дегтя подстерегает нас в сообщениях системы о ошибках и/или неправильных действиях пользователя. Когда я занимался доработками 1С на условиях фриланса и у меня было десятка полтора-два мелких клиентов, то я очень быстро приучился предвидеть и программно обрабатывать возможные ошибки и неправильные действия пользователей. Причина была проста – как только у пользователя возникала необработанная ошибка, он тут же мне звонил с претензией «у меня НИЧЕГО не работает!» и начинались долгие и нудные выяснения: а что вы делали? А как? А что нажимали? И т.п. При этом я, как правило работал у другого клиента и это не нравилось никому – ни мне, ни первому клиенту, ни второму. Поэтому я взял за правило – каждый чих в программе обрабатывать на предмет возможных ошибок или не верных действий пользователя и максимально выдавать в сообщениях всю имеющуюся информацию (даже если она на первый взгляд кажется избыточной).
В АХ, к сожалению, не все так просто. Зачастую система выдает мало информативные, а то и совершенно непонятные сообщения, которые способны застопорить работу малоопытного консультанта или пользователя на несколько часов или даже несколько дней. И начинаются длительно-мучительные поиски ответа в гугле, на тематических форумах. Которые, хочу заметить на 99% англоязычные. И если прибавить к этому слабую документированность локализованных решений, то картина для украинского потребителя получается совсем уж безрадостная: 1) заплати дорого 2) описания нет или устаревшее/скудное 3) получай малопонятные и противоречивые ошибки.
Конечно, объяснение сложившейся ситуации есть (но не оправдание я считаю). Что касается малоинформативных сообщениях, то тут одна из причин – объектно-ориентированный подход встроенного языка. С точки зрения многократного использования программного кода – вещь абсолютно правильная, нужная и классическая. Но у всего есть оборотная сторона медали. Если в 1С программист практически всегда владеет контекстом и понимает, чем вызвана ошибка (встроенный язык 1С является НЕ объектно-ориентированным компилятором, а Бейсико-подобным интерпретатором), то в АХ зачастую в момент возникновения ошибки мы находимся где-то в глубине наслоений кода, как в самой последней матрешке, которая входит в несколько десятков матрешек покрупнее. И для того, чтобы понять, что же сделал неправильно пользователь на самом верхнем уровне, необходимо передавать через все уровню множество информации, которая в 99% случае НЕ пригодится, и только для того, чтобы в случае ошибки полнее информировать пользователя о неправильных действиях. На практике большинство программистов «забивают» на это, рассуждая что консультант (пользователь) ОБЯЗАН знать функционал и не делать ошибок.
Чтобы было понятнее, о чем это, приведу практический пример, с которым лично столкнулся на практике. Имеем приходную накладную с накладными расходами: купили какие-то товары и понесли накладные расходы по доставке/сборке и т.п. Разносим, т.е. формируем движения в учетных регистрах («проводим» в терминах 1С). Система выдает не очень понятное сообщение, из которого можно догадаться что что-то не то с валютой. Причем непонятно где: в товаре, накладных расхода, карточке поставщика, договоре, взаиморасчетах. Документ НЕ валютный, все в национальной валюте – и товар и услуги. Из текста самого сообщения непонятно, где и почему задействована валюта.
Опытные консультанты «чувствуют» где подвох и часто по опыту знают куда надо зайти и что проверить. Неопытные начинают строить различные предположения и проверять их. Это долго, утомительно и малоэффективно. Есть еще тематические форумы, там сидят скучающие маститые гуру АХ, которым нравится помогать новичкам J Вот они часто и спасают. Но опять-таки это долго. Потому что им же нужно сначала понять детально ситуацию, проверить массу вещей. Гугл мало помогает потому, что проблема с валютой может возникать в массе случаев и всегда выдается примерно одинаковое сообщение.
В конечном итоге потратив полдня оказалось, что в накладных расходах на покупку не была указана валюта, а в товарах стояла валюта гривна. Система вместо того, чтобы сообщить в «накладных расходах не указана валюта», а еще лучше сделать это поле обязательным, просто не обрабатывала эту ситуацию как ошибку, а в итоге вываливалась с ошибкой уже только тогда, когда в процедуре пересчета из валюты в валюту просто возникала (по сути не обработанная) ошибка. Если открыть стек вызовов вложенных процедур, то это был бы 10-15 уровень вложенности. Неужели нельзя было на более ранних этапах проверить и выдать сообщение?!
Нет, не то чтобы в 1С не бывает ошибок или что все они обработаны. Просто в силу специфики языка интерпретатора нет навязанной классами жесткой программной структуры, и организация функций и процедур в основном дается на откуп разработчика.
Конечно, при грамотном проектировании классов и хорошем их знании любые доработки делаются точечно и с минимум усилий, но на практике чаще всего бывает немного по-другому. На практике качество проектирования системы, и классов, в частности, сильно зависит от опыта главных консультанта и разработчика (архитектора). Опытные стоят дорого, а все же хотят сэкономить… В конечном итоге там, где в 1С можно отделаться малой кровью и переделать за неделю до сдачи, в АХ придется вернутся к исходному классу и переделать все наследованные.
Аудиторский след и запрет повторного разнесения документов.
Все споры на тему что лучше 1С или международная ЕРП-система так или иначе быстро сводятся к вопросу аудиторского следа в системе. Т.е. насколько бесследно можно исправить тот или иной «косяк» или сознательную махинацию. В развитых странах существуют законодательные требования к ЕРП-системам обеспечить так называемый «аудиторский след», т.е. чтобы проверяющий мог убыть уверен, что он видит всю историю транзакций, включая все исправления. Т.е. чтобы любой, кому это необходимо мог увидеть кто, когда, в каком виде внес документ и кто, когда что именно в нем исправил. Причем независимо от того, сколько раз и в каких масштабах делались изменения (надо найти ссылочку на законы).
То, что споры идут вокруг этого принципа очень логично, так как по большому счету это действительно единственный системный «недостаток» именно платформы. Все остальное – очень субъективно и может быть в принципе реализовано как в одной, так и в другой системе. Вопрос только сроков-стоимость-качества.
Действительно, возможность сколько угодно раз повторно проводить документ в 1С может (и часто так бывает) приводить к некорректным данным и конфликтным ситуациям. Причина проста: движения одного документа могут является основанием (входными данными) для другого. И когда мы бесследно удаляем (переформируем) эти движения, то второй документ (наследник) как бы подвисает – непонятно на чем он был основан. Простой пример: купили товара по 1.00, провели приходную накладную, он поступил на склад. Продали по 2.00, провели расходную. Потом обнаружили ошибку в приходной накладной и исправили цену закупки с 1.00 на 1.50. А в это время отчет о продажах уже лег на стол руководства и на его основании уже были приняты управленческие решения.
Но вопрос: является ли это недостатком системы? Я считаю, что это недостаток не системы, а уровня организации ведения учета. Говорят, все, что сделано человеком, может быть сломано человеком. Т.е. я бы не стал на 100% доверять данным в ЕРП-системе пока есть человек с административными правами на уровне сервера СУБД (а он по определению есть). Потому что не составляет особого труда с помощью того же SQL Management Studio аккуратненько почистить следы везде где надо. С другой стороны, точно так же ничего не мешает в 1С убрать у всех права на повторное проведение документов и получить тот же аудиторский след. Который точно так же сможет подчистить пользователь с административными правами. Только в данном случае будет достаточно админ. прав в 1С, а не на уровне СУБД. А так ли это важно? Результат-то один.
Но обратная сторона медали на мой взгляд крайне важна. В 1С при грамотной организации учета и документооборота можно просто держать открытым для редактирования небольшой оперативный период (например, текущий день/неделю) в рамках которого можно бесследно и «безнаказанно» исправлять все что угодно. Т.е. как правило «косяки» вылезают почти сразу – привезли ошибочную накладную от поставщика, внесли в систему, провели. Выяснилось, что в ней ошибка – созвонились, передали исправленную, исправили в системе – перепровели. А вот если уже период закрыт, то внесение исправлений должно происходить по существенно другому бизнес-процессу и другими людьми, которые понимают последствия своих действий и обладают необходимыми полномочиями и ответственностями.
Точно так же и потребители отчетности (как правило руководство) должны понимать что формируя отчет в открытом периоде не стоит сильно им доверять и принимать серьезные решениях на их основании – все еще может измениться.
Мне могут возразить – в АХ пользователи отсторнируют ошибочный документ и в системе останется след: 1) ошибочный документ – время, автор 2) сторно документа – время, автор 3) правильный документ– время, автор. Все верно, но вот в чем вопрос: такой ли уж ценной будет эта информация? А ведь она останется в системе навсегда. А представьте тысячи пользователей и десятки тысяч документов. При этом ухудшается наглядность и читабельность отчетов. Простой пример – сделайте сверку взаиморасчетов с контрагентом в ситуации, когда ошибки исправлены с помощью повторного проведения (один документ – одно движение) и в ситуации, когда каждая ошибочная ситуация сторнируется (причем часто не сразу, а гораздо позже) и потом идет исправленный вариант. Разработчики АХ это понимают и пытаются облегчить жизнь пользователей – например выделяют цветом в отчетах сторнирующие и исходные документы.
Поэтому в данном вопросе я бы сказал, что это дело вкуса и предпочитаемых подходов к организации учета. Кому-то нравится хаос в оперативном период, но зато потом «чистенько-нарядно» в долгосрочной перспективе, а кто-то любит ВСЕ контролировать и в любой момент «отмотать назад», пусть и ценой некоторой «не нарядности» отчетов. Обе системы при большом желании позволяют сделать и так, и так, просто на уровне платформы (без «извращений») в системах исповедуется диаметрально противоположный подход.
Качество и полнота украинской локализации.
Этот пункт, на мой взгляд, один из самых сильных аргументов в пользу 1С и против АХ. Причем, к моему сожалению, российские пользователи оказались в гораздо более выгодном положении чем украинские. Дело в том, что для российского рынка существует официальная (утвержденная/одобренная/признанная) локализация от Майкрософта. Для Украины локализации нет. Это значит, что купив лицензии и установив систему российский пользователь получит единую локализацию к какому бы партнеру Майкрософт он не обратился за покупкой лицензий и внедрением. В Украине, опять же, к сожалению, практически каждый партнер пишет (и далее поддерживает) свое решение по локализации. Причины такого положения очень просты и лежат в области экономики. Майкрософт компания коммерческая (хоть и очень богатая) и работает ради получения прибыли. Объем российского рынка превосходит украинский минимум на порядок. При таком мизерном объеме украинского рынка Майкросфоту просто экономически не выгодно вкладывать деньги в локализацию. Потребители же наоборот не могут без неё работать в системе. Вот и получается, что партнеры вынуждены разрабатывать локализацию практически за свой счет.
У 1С все решения изначально, разумеется, российские, но с локализацией дела обстоят существенно получше. Очень давно (уже почти 20 лет) существуют версии российский конфигураций, адаптированных под требования украинского законодательства. В Украине давно работают крупные компании-франчази, занимающиеся разработкой типовых решений и внедрением их в Украине, такие, как например ABBYY Украина. Локализованные украинские конфигурации используют тысячи (если не десятки тысяч) украинских предприятий. И, само собой разумеется, что постепенно локализованные конфигурации развивали функционал и учитывали огромное количество разнообразных требований законодательства и пожеланий пользователей.
В итоге складывается такая ситуация что компания, внедряющая АХ в качестве конкурентного преимущества указывает поддержку, к примеру просто налоговых накладных и основных требований законодательства в части учета НДС, в то время как решения на базе 1С уже давно поддерживают очень сложные и редкие схемы учета НДС.
Если кому-то кажется, что я не объективен или сгущаю краски, предлагаю провести простой эксперимент. Пригласите на показ системы представителей компаний-внедренцев и попросите показать в системе (не просто слайды) основной цикл хозяйственных операций: покупка, продажа, оплата. Там, где у 1С будет множество настраиваемых параметров и сложных схем учета НДС в разных режимах, у АХ будет просто основная схема, с очень скудными возможностями. Безусловно, вам расскажут, что все что необходимо вашей компании будет написано специально для вас и именно так, как вам надо. Но вы же понимаете, что функционал, заложенный в типовое тиражируемое решение и написание под заказ — это немного разные вещи.
На мой взгляд, наиболее удачным является комплексное решение, когда системы интегрируются и каждая из систем используется для того, для чего она лучше всего подходит. Например, в АХ ведется транспортная и складская логистика плюс производство, в 1С бухгалтерский и налоговый учет, зарплата и кадровый учет. При этом обновления под изменяющиеся требования законодательства в 1С выходят чуть ли не через несколько дней после вступления требований в силу, что очень удобно – конфигурации можно обновлять очень оперативно и пользователи получают новый функционал практически сразу.
Конечно, можно спорить, в какой системе логистика, склад производство и другие модули лучше проработаны – в АХ или 1С. Но спорить, где лучше реализован бухгалтерский, налоговый, кадровый учет и расчет зарплаты – на мой взгляд, в настоящий момент просто бессмысленно.
Но любая интеграция — это конечно палка о двух концах и идеальным такое решение конечно же назвать сложно.
Масштабируемость и производительность.
В данном вопросе перевес практически всегда был на стороне AX. Я бы даже сказал, это зачастую бывает основной и единственный аргумент. Заказчик рассуждает примерно так: «Мы компания крупная, у нас сотни активно работающих пользователей и на такие нагрузки 1С просто не рассчитана! Поэтому мы выбираем более производительную систему». В целом это верное утверждение, но если проанализировать изменения в платформе 1С за последние 3-5 лет, то четко прослеживается тенденция повышения масштабируемости и производительности именно для сегмента крупных клиентов.
В конечном итоге через 2 года работы консультантом по AX я вернулся к работе с 1С о чем абсолютно не жалею и получаю от работы истинное удовольствие. Работа с АХ расширила мой профессиональный кругозор и заставила больше ценить 1С и не комплексовать перед «серьезными взрослыми системами», которые на поверку оказались не такими уж и крутыми.
