О системах планирования ресурсов предприятия Scala, iScala
“ Вчера пообщался с двумя своими коллегами-консультантами на тему "пространства iScala" и того, что вокруг него. И по поводу подходов к внедрению систем, и по поводу тех, кто этими внедрениями занимается, и по поводу перспектив тех или иных систем после ухода из России ERP-монстров. И в процессе общения либо я, либо мой собеседник произнесли точь в точь одни и те же слова. Слово в слово. Ну, а "бедному крестьянину" волноваться и куда-то бежать не стоит, разве что сделать обновление со старой версии на более свежую...
  • Главная
    • О проекте
      • Разъяснение о проекте и его участниках
      • Заявление / 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  »»»  Куда «бедному крестьянину» податься?

Куда «бедному крестьянину» податься?

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

Многие зарубежные ERP «монстры» ушли из России. Да и Эпикор, если честно, ведёт себя по-идиотски, на его сайте вообще ничего нет, кроме каких-то дурацких маркетинговых лозунгов, а Россия, как страна там вообще отсутствует. Ну, как говорится, и «флаг им в руки», да вот только чего делать клиентам программных продуктов, у которых есть выбор? Я не имею в виду госкомпании, которым, скорее всего скомандуют, что им делать, и это абсолютно понятно, я бы на месте государства тоже озадачился этой проблемой, но что по поводу простых клиентов iScala, стоит ли им задавать вопросы: «вдруг iScala 3.5 была последней версией продукта»? Стоит ли волноваться?

Рабочее место

Я лично так не думаю. Нет, я допускаю, что сейчас в некоторых компаниях могут резко активизироваться скалоненавистники, которые попытаются подвигнуть руководство сменить систему, например, на 1С ERP. Начнём с того, что это оксюморон. Я считаю, что в России нет собственных программ, аналогичных по своему уровню САПу, Ораклу или айСкале, уж во всяком случае то, что называется на одну цифру и одну букву — это явно не замена. То, что нам преподносят как ERP систему таковой не является и это тоже понятно, так как изначально там совершенно другой (бухгалтерский) подход: дебет — кредит, дебет — кредит и ничего больше. Всё остальное натягивали поверх этого. Но вопрос даже не в этом. Главных вопросов два: первый — система является не параметрически настраиваемой, как iScala, а программируемой, в результате чего каждая компания имеет свою собственную уникальную систему, не похожую на систему в соседней компании. Как её задумал программист и как ему поставил задачу представитель заказчика, очень слабо понимающий, что такое система, которая обеспечивает информацией потребителей во всех сферах деятельности компании, а не только бухгалтеров или продавцов. А второй вопрос вытекает из первого: а кто этот самый программист? Я общался с большим количеством таких, с позволения сказать, специалистов и, извините за нетолерантность, все они уроды, ну или почти все. С ними невозможно ни о чём говорить, они ничего не слушают и не слышат, они ничего не могут объяснить простыми словами. Они живут в своей собственной реальности. Они понимают только то, что соответствует терминологии их системы, это самая натуральная «секта». Конечно, встречаются и по-настоящему профессиональные специалисты, но за 28 лет мне довелось пообщаться не более, чем с двумя такими профи.

Ну, ладно, это я отживаю вчерашнее общение с моими коллегами. Теперь вернёмся к айСкале. Я считаю, что существующим клиентам айСкалы волноваться не о чем. Даже, если предположить, что iScala 3.6, выход которой был запланирован на апрель 2022 года, но так и не случился пока, будет на данном отрезке времени последним обновлением системы, то меня лично это совершенно не пугает вот по каким причинам:

  • А много ли революционных изменений в функциональности появилось в последних версиях?
  • А вы знаете, на каких версиях продукта до сих пор «сидят» некоторые клиенты?

Начну с первого вопроса: Да, некоторые «революционные» изменения в последних версиях произошли, но произошли они в системе построения отчётности. У меня есть знакомые компании, которые перешли на новые версии, например, iScala 3.5, но всем этим не пользуются. И есть другие клиенты, которые уже давно ушли вперёд в плане построения «внешних» отчётов по сравнению с разработчиками Эпикора. Им все эти изменения побоку. Так что «есть ли жизнь на Марсе (новые версии), нет ли жизни на Марсе», нас это волновать особо не должно, применительно к текущему моменту как минимум. Не подумайте, что я агитирую не переходить на новые версии, наоборот, я всегда «за», правда без излишнего фанатизма. Переходить на что-то новое нужно не тогда, «когда можно», а когда «нельзя не перейти». В большинстве случаев сейчас можно найти довод «нельзя не перейти», но только в отношении новой версии, а не новой системы! Особенно, это касается тех, кто более 15 лет «сидит» на старых версиях продукта. И тут мы плавно переходим ко второму вопросу: если люди ещё полгода назад пользовались версией Scala 5.1 (для тех, кто не знает что это — это то, что было до iScala) и им удавалось получить всё что было необходимо в работе, то представьте, какой запас прочности у iScala 3.5 или iScala 3.6 (я надеюсь, что она в ближайшее время всё-таки появится).

Рубрика: IT & ERP Метки: ERP, параметрическая система, программируемая система, программист
VK Telegram Про канал в WhatsApp

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

Gammapolis WordPress Theme by ERP & Business Consulting

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