О системах планирования ресурсов предприятия Scala, iScala
“ Попытаюсь порассуждать о сильных и слабых сторонах iScala исходя из собственных представлений о том, что есть хорошо и что есть "не очень". Разумеется, это мой личный субъективный взгляд.
  • Главная
    • О проекте
      • Разъяснение о проекте и его участниках
      • Заявление / Memorandum
    • Новости проекта
    • Список опубликованных материалов основного раздела
    • Информация, перенесённая из старых форумов
    • Подписаться на новостную рассылку
  • Статьи
    • Статьи
    • Избранное
    • Мысли вслух
  • Процедуры
  • Доходчиво о сложном
    • Обучение
    • Как сделать?
    • iScala «для чайников»
    • Оч.умелые ручки
  • Структура таблиц
    • Scala 5.1 SR13
    • iScala 2.2 HF 2.3318
    • Tables structure changes history from iScala 2.2 SR2 to iScala 3.0 FSP4
    • Epicor iScala 2.3 — 2.03.3363
    • Epicor iScala 2.3 SR1
    • Epicor iScala 2.3 SR2
    • Epicor iScala 2.3 SR3
    • Epicor iScala 3.00 FSP 2 — 3.00.02254
    • Epicor iScala 3.0 FSP4 — 3.0.4267
    • Изменение структуры таблиц iScala 3.1 по сравнению с iScala 3.0 FSP4 / Table structure changes between iScala 3.0 FSP4 and iScala 3.1
    • Epicor iScala 3.1 — 3.1.0511
    • Epicor iScala 3.2 — 3.2.0317
    • Epicor iScala 3.3 — 3.3.0419
    • Epicor iScala 3.4 — 3.4.0399
    • Epicor iScala 3.5 — 3.5.0.0429
    • Изменение полей в таблицах БД iScala 3.4 по сравнению с iScala 3.2 / Difference between DB structure of iScala 3.4 and iScala 3.2
    • Изменение полей в таблицах БД iScala 3.5 по сравнению с iScala 2.2 / Difference between DB structure of iScala 3.5 and iScala 2.2
  • Материалы по модулям iScala
    • Главная Книга
    • Основные Средства
    • Книга Закупок
    • Книга Продаж
    • Заказы на Закупку
      • Требования
    • Заказы на Продажу
    • Управление Запасами
    • Установка, Администрирование
      • Настройка определений документов MSRS
    • Заработная плата
    • Структура базы данных
    • Отчётность SSRS
    • Отчётность AFR
    • Примеры отчётов
    • Примеры отчётов AFR
    • Интеграция с другими системами
    • Epicor Service Connect
  • English
  • Контакты
  • Поиск
Главная  »»»  IT & ERP  »»»  В поисках идеальной ERP системы. Сильные и слабые стороны iScala

В поисках идеальной ERP системы. Сильные и слабые стороны iScala

16.02.2019 Автор Алексей Васильев

Вчера разговаривал с потенциальным клиентом. Один из вопросов был: «а какие у 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, желательно иметь собственного администратора системы. Это не обязательно, но крайне желательно.

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

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

Рубрика: IT & ERP, Избранное Метки: iScala, Reporting Services, Service Connect, кладовщик, параметрическая система, проводка, склад, счёт, счёт-фактура
VK Telegram

Copyright © 2023 О системах планирования ресурсов предприятия Scala, iScala.

Gammapolis WordPress Theme by ERP & Business Consulting

Прокрутка вверх