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

Ошибочная бизнес-модель 2.0

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

Материал на эту же тему от 2009 года читайте здесь.

За последние несколько месяцев получил 3 письма на тему услуг по iScala от специалистов … по закупкам (!). Если первое письмо вызвало недоумение, второе — ощущение недоразумения, то последнее буквально взбесило. Ибо 3 письма — это уже тенденция.

Ошибочная бизнес-модельС одной стороны, посыл понятен, хотят стандартизировать процесс, сбор разных предложений от разных поставщиков и т.п. А с другой, извините меня за не толерантное высказывание, но это полнейший идиотизм. Это при закупке болтов или гаек хороший сценарий, ну, может быть даже при покупке оборудования. Погуглил, сравнил цены, сроки поставки, запросил условия договора и вперёд, гайки, они и есть гайки, если не миллион штук покупаешь. Но здесь, дорогие закупщики (я против вас лично ничего не имею), вы «не в теме». И не можете вести переговоры. Этим должны заниматься специалисты, работающие с системой. А я, со своей стороны, могу только это вам разъяснить, но никаких коммерческих предложений высылать не намерен, особенно в случае, когда меня просят оценить, сколько будет стоить поддержка не только iScala, а ещё и третьестороннего софта и я предполагаю, что разработчику этого же софта направлен аналогичный запрос. Глупо пытаться «ковыряться» в чужой разработке, разработчики это сделают лучше. Я никогда не буду участвовать в тендере на поддержку третьестороннего софта, где один из участников – его разработчик, это смешно, на мой взгляд. И, да, мне неприятно, когда меня держат за статиста. Ведь ежу ясно, что выберут компанию, которая этот софт разработала, я даже знаю, как она называется. И ничего против этого не имею. Вот только готовить коммерческое предложение потому, что чья-то процедура подразумевает наличие нескольких предложений, тоже не намерен, до свидания, дамы и господа! И моё уважение к подобной компании резко падает, я, по-возможности, воздержусь от работы с ней.

А теперь о том, как эта тенденция мною интерпретируется. Во-первых, она очень неприятная. Попытка всё упростить и формализовать. Так можно дойти до того, что выбирать поставщика решений по количеству лайков в инстаграме. В результате получишь то, что получишь. Во-вторых, это «звоночек» о том, что ИТ в данной компании «задвигают» или его воспринимаемая ценность упала. К чему это может вести в моей практике примеров множество. Вот, в частности, в одной из компаний, фрагмент письма от которой можно увидеть на картинке выше, квалификация собственных ИТ сотрудников настолько не соответствует уровню системы, что компания всерьез рассматривает вариант перехода на систему попроще. Перефразируя рекламный слоган L’Oreal Paris, «наверное, только этого вы и достойны»…

ИТ подразделение, где от него что-то зависит, это, на мой взгляд, стратегическое подразделение компании, стратегический актив. Разумеется, там, где руководство смотрит на это аналогичным образом. А если нет, тогда так им и надо 🙂

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

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

Gammapolis WordPress Theme by ERP & Business Consulting

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