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

О реактивном и проактивном поведении в ИТ

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

На позапрошлой неделе Сапсан, в котором я ехал из Санкт-Петербурга в Москву, опоздал более чем на 2 часа и всем пассажирам заранее раздали конверты с бланками претензии. Я не стал его сразу заполнять, так как, во-первых, не хотелось заполнять всё это вручную, включая 12-значный ИНН, 20-значные расчётный и корреспондентский банковские счета, а, во-вторых, не наизусть же это всё помнить. Решил, что заполню аналогичный бланк прямо на сайте РЖД.

Однако оказалось, что на сайте РЖД нет формы, которую можно было бы заполнить онлайн, несмотря на то, что билеты я всегда покупаю именно онлайн, нужно скачать PDF файл, распечатать его на принтере и заполнить вручную. То есть, они даже не сделали PDF с заполняемыми полями, это просто картинка. Нет, я понимаю, что на бланке должна быть моя подпись в двух местах, но вся остальная информация! Зачем её заполнять вручную, ведь можно это сделать, как при заполнении визовой анкеты, когда вы всё заполняете онлайн, затем формируется PDF файл, вы его печатаете и подписываете, а самое главное, никто потом не сидит и не перебивает всю информацию с вашего листка бумаги вручную, в конце визовой анкеты несколько QR кодов, содержащих закодированную информацию. Но только не в форме претензии РЖД. Вы представляете, сколько народу отправляет такого рода бланки? И после этого кто-то сидит и вколачивает это в компьютер с бумажки, заполненной корявым почерком. 🙁

Но, разумеется я это всё пишу не для того, чтобы пожаловаться на РЖД. Просто эта ситуация напомнила мне совсем другую историю, связанную с компанией, которая мне значительно ближе, чем РЖД.

Последние 8 лет я наблюдаю, что происходит с информационной системой на базе iScala в одной знакомой мне организации. Сначала существующую iScala пытались клонировать и начать с чистого листа, мотивируя такое странное решение тем, что данные не вызывают доверия, мол ввести вступительное сальдо проще, чем исправлять то, что неправильно. Это был целый проектище! Не комментируя целесообразность такого решения, я всё-таки нашел в этом что-то положительное, решив, что раз всё с чистого листа, то тогда можно исправить некоторые неправильные решения, принятые в самом начале проекта внедрения и доставшиеся «по наследству» тем, кто вынужден был с этим жить. Да и версию обновить не мешало бы, это особенно удобно, когда данных нет, только вступительное сальдо. Оказалось, что ничего подобного, никто ничего пересматривать не собирается, ни процедур, ни настроек, ни версии. Странно, однако… Ну, ладно…

Затем через несколько лет появился ИТ сотрудник, который привык к тому, чтобы система была для пользователей, а не пользователи для системы. И ему удалось кое-что изменить при молчаливом согласии ИТ руководителя. И новую версию установили, и интеграцию с системой электронного обмена документами сделали так, что основные покупатели стали присылать заявки на покупку в электронном виде, а эти заявки автоматически загружаться в iScala. И многое другое сделали.

И вот ещё через несколько лет этот сотрудник покинул компанию, нашёл более заинтересованного работодателя. Время идёт, а в компании в сфере ИТ опять начался застой. Что меня беспокоит? Всё дело в том, на мой взгляд, что если ИТ подразделение в общем и ИТ руководитель, в частности, не занимают проактивную позицию, а ведут себя реактивно, отыгрывая только текущую рутину, система начинает стагнировать и превращаться в свою противоположность, не помогает, а нагружает дополнительной работой. Прямо как в ситуации с бланком претензии РЖД. Процессы меняются, но никто не предлагает каких-либо улучшений, никто не думает об управлении информацией, думают в лучшем случае о технологиях. Недаром у нас и должности часто называются «Директор по информационным технологиям», а у наших англоязычных коллег «CIO — Chief Information Officer», чувствуете разницу? Правда некоторые коллеги в шутку расшифровывают это иначе Career Is Over (карьера закончена) 🙂

Самое печальное, что уходят наиболее квалифицированные сотрудники, которые что-то хотят, остаются середнячки, которым вполне комфортно в своём «болоте» 🙁

Мне небезразлична эта организация, но что я могу сделать в этой ситуации? Если нет кого-то, кто готов хотя бы услышать мнение со стороны, то как этому помочь? Ни один психолог не сделает человека счастливым, если он сам этого не захочет, или, по крайней мере не обратится к психологу 🙂

Я даже не знаю, кто теперь принимает решения, захочет ли он узнать моё мнение… И как объяснить, что у меня нет никакой личной заинтересованности? Я ни наниматься на работу в эту компанию не собираюсь, ни заключить договор особо не стремлюсь. Буду просто наблюдать, как всё разваливается… А вдруг кто-то из принимающих решение прочитает мой «поток воспалённого сознания»? Мало шансов…

А вы что об этом думаете? Надеюсь, вам это никого не напоминает…

Рубрика: Мысли вслух Метки: ERP, iScala, заказ, руководитель, система, сотрудник
VK Telegram Про канал в WhatsApp

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

Gammapolis WordPress Theme by ERP & Business Consulting

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