Вчера разговаривал с потенциальным клиентом. Один из вопросов был: «а какие у iScala сильные и слабые стороны?». Трудный вопрос. Не потому, что он трудный сам по себе, а потому что не может быть просто сильных или слабых сторон у любой системы, сильные или слабые стороны могут быть только в сравнении с чем-то другим, с какой-то другой системой. В России всегда всё сравнивают с системой, название которой состоит из одной цифры и одной буквы (не хочу произносить это вслух). У неё более миллиона инсталляций и по распространённости ничто не может с ней сравниться. Но я не являюсь специалистом по этой программе, хоть и имею некоторое представление, а потому попытаюсь порассуждать о сильных и слабых сторонах iScala исходя из собственных представлений о том, что есть хорошо и что есть «не очень». Разумеется, это мой личный субъективный взгляд.

Начнём с того, что каждый видит идеальную систему по-своему. Как вам вот такой взгляд (попытка всё разместить на одном экране)?

Наверное для этой системы идеальной клавиатурой будет вот такая:

А если серьёзно, то это образец худших практик в области программирования и дизайна программ. Хотя кому-то, возможно, очень нравится 🙂

А теперь поговорим об iScala

Сильные стороны:

Самой сильной стороной iScala, на мой взгляд, является то, что это параметрически настраиваемая система. Что это такое достаточно подробно описано в моей статье «Путь в тупик» или «Так ли дёшева самописная интегрированная система управления предприятием?»

Если кратко, то параметрически настраиваемые – это системы настраиваемые с помощью параметров. Эти параметры могут быть «Глобальными» или относиться к одному отдельно взятому филиалу и/или отдельному финансовому году. Параметры могут быть независимыми или взаимозависимыми, когда действие одного параметра может менять действие другого параметра. Количество этих параметров в зависимости от используемой функциональности может измеряться сотнями и даже тысячами, а их настройка должна выполняться самыми опытными сотрудниками и/или консультантами по внедрению системы, простой пользователь не должен уметь это делать.
В противоположность первым, программируемые системы подстраиваются под требования бизнеса не посредством правильного ответа на вопрос-параметр, а «дописыванием» программного кода

Теперь чуть подробнее о параметрически настраиваемых системах:

Плюсы: Универсальность: Наличие поддержки со стороны поставщика программного продукта, возможность пользования услугами службы поддержки «Горячая линия», масштабируемость, лёгкость обновлений версий, небольшое время, которое должен затратить «внешний» консультант, чтобы разобраться, как именно должна работать Ваша система.

Минусы: Недостаток гибкости: Если нельзя сделать «в лоб», приходится придумывать обходные пути. Из-за необходимости системы при работе проверять большое количество параметров, быстродействие может быть ниже, чем у «программируемой» системы.

Примечание: На мой взгляд, плюсы такого подхода намного существеннее минусов

Что даёт такой подход? А даёт он очень важную вещь: Универсальность. Настроив систему под свои нужды с помощью набора параметров, Вы можете быть уверены в том, что, обратившись по телефону к консультанту «Горячей линии», он должен Вам помочь. А установка новой версии параметрически настраиваемой системы не приводит к необходимости полностью переписывать всё то, что было «нажито непосильным трудом» (программистов).
Разумеется, всегда имеется и оборотная сторона медали: меньшая гибкость

В современных версиях iScala имеется большой спектр дополнительных возможностей увеличить эту гибкость: механизм интеграции с другими системами или внутри самой iScala, называемый Epicor Service Connect, который может работать с участием или без участия пользователя, возможность использовать встроенный язык программирования VBA (в редких случаях, когда без этого совсем никак не обойтись), так называемые «быстрые поиски» и другое.

Второе важное преимущество iScala — открытость к лучшим технологиям: использование всех возможностей сервера баз данных Microsoft SQL Server, включая лучшее, на мой взгляд, средство построения отчётности MS SQL Server Reporting Services. Если в российских бухгалтерских программах часто используются собственные форматы хранения информации, а для построения отчётов нужно пользоваться «внутренними» инструментами, как и для их просмотра обязательно нужно «входить» в систему, то при создании отчётов на базе информации из iScala можно пользоваться широко распространёнными инструментами, а для просмотра отчётов не обязательно быть пользователем системы. Так, например, в компании ООО «СоюзБалтКомплект», где я работал директором по ИТ с 2004 по 2009 годы пользователями iScala были около 75 человек, тогда как отчёты кроме этих 75 пользователей могли просматривать еще около 150 человек, которые даже не знали, как выглядит iScala. Отчёты можно запускать по расписанию и получать по электронной почте.

Третье преимущество — протоколирование изменений и невозможность бесследно удалить введённые документы и проводки

В частности, если вы ввели счёт-фактуру покупателю (и/или оправили бухгалтерскую проводку в Главную Книгу), то вы не можете её удалить, только ввести исправительный счёт-фактуру (или проводку). Возможно, бухгалтера, привыкшие всё «подчищать», так, чтобы «не оставалось никаких следов», скажут, что это не преимущество, а недостаток, но я с этим не соглашусь, т.к. возможность скрывать сделанные изменения часто приводит к злоупотреблениям и/или хищениям.

Четвёртое — сквозное движение информации и распределение обязанностей. Информация в системе движется от одного человека к другому. Начинает вводить один человек, например, сотрудник отдела сбыта, на ее основе продолжает работу другой человек, например, сотрудник производственного отдела, далее подхватывает третий, сотрудник отдела снабжения. Затем — кладовщик, принимая материалы на склад, далее — бухгалтер, вводя счета-фактуры на закупленные материалы и транспортные расходы с привязкой к конкретной закупке и т.п. И снова — производство, сбыт и т.д. И каждый из них должен обеспечить определенную степень подробности, необходимую тем, кто является получателем информации, будь то сотрудник, стоящий следующим в цепочке ее движения, или руководитель, ее конечный получатель, а система с помощью сделанных настроек делает так, что по результатам работы кладовщика, который понятия не имеет о бухгалтерских счетах, создаются правильные бухгалтерские проводки по складу. В последних версиях iScala появились мобильные приложения, которые позволяют сотрудникам склада использовать смартфон и встроенную в него фотокамеру, чтобы сканировать штрих-коды и совершать действия в системе не отходя от полки с товаром. А руководитель может утвердить заявку на закупку со своего смартфона прямо из салона автомобиля.

А ещё iScala работает на 30 языках во многих странах мира 🙂

Слабые стороны, разве может их не быть?

Самая серьезная слабая сторона — отсутствие достаточного количества потенциальных сотрудников со знанием iScala. В России все бухгалтера умеют работать с программой (не будем называть её название) и ничтожно малое их количество умеют работать с iScala.

Кроме этого по мнению пользователей: «такая дорогая программа, в неё ещё и данные нужно вводить?!!!» 🙂 Да, в iScala нужно вводить данные (за исключением данных, поступающих с помощью механизма Epicor Service Connect), в неё не встроен искусственный интеллект. А пользователь вносящий данные должен быть адекватным и понимать, что он делает, а не просто махать сканером штрих-кодов «направо и налево». Новому сотруднику желательно пройти внутреннее обучение в рамках процедур вступления в должность.

Компаниям, использующим iScala, желательно иметь собственного администратора системы. Это не обязательно, но крайне желательно.

Она не умеет варить кофе и делать бутерброды 🙂

В индивидуальных случаях у некоторых пользователей может быть аллергия на отдельные компоненты системы из-за предвзятого отношения и нежелания принимать всё, что выглядит иначе, чем он привык 🙂