Comments 41
А при чем тут excel? В Сибуре не смогли закупить LMS систему, изза чего сотрудники были вынуждены использовать excel(хотя на рынке есть более эффективные решения).
Уж для такого размера компании лицензия на LMS это копейки, в рамках трат холдинга.
Даже если предположить что денег было жалко(или нужен контроль над данными ), есть опенсорс в виде Moodle(3 место в мире среди суо), где уже есть матрица компетенций, контроль обучения, онбординга и пр
Просто бизнес, ничего личного )
Это СИБУР. Упор на свои разработки, базирующиеся на крупицах мирового опыта и достижений. Просто - менеджмент (см. комментарий Oceanshiver)...
Уж для такого размера компании лицензия на LMS это копейки
Вы так говорите, как будто закупить лицензию - это прямо основная сложность.
опенсорс в виде Moodle
То же самое. Один фиг допиливать, интегрировать со своей ИТ-средой и своими процессами, и совсем не факт, что при наличии внутри компании нужных компетенций запилить свое не будет проще и дешевле.
Жаба — самый страшный монстр. Мало кому удавалось одержать над ней победу в честном бою!
В СИБУРе всё, что создаётся или внедряется, направлено на повышение эффективности производственных процессов. Поэтому задача стояла не просто в том, чтобы заменить Excel на стандартную LMS, а в том, чтобы создать инструмент, глубоко интегрированный в производственные процессы.
Нам был нужен не просто планировщик, а система, которая в реальном времени связана с данными об отпусках и отсутствиях, графиками плановых ремонтов и т. д. Например, чтобы при оформлении больничного система автоматически переносила сроки обучения и информировала ответственных, а также учитывала доступность на этот период наставников соответствующей категории, обладающих достаточными компетенциями. Стандартная LMS, включая такие мощные платформы, как Moodle, работает изолированно от таких данных.
Интеграция же готового решения потребовала бы серьёзных доработок «коробки», что действительно сопоставимо по стоимости с собственной разработкой. Но ключевым фактором стало даже не это. Наша команда провела много времени на производственных площадках, непосредственно общаясь с оперативным персоналом и целевыми пользователями. Сомневаюсь, что внешние подрядчики позволили бы себе такое же глубокое погружение в контекст.
Поэтому, сравнив общую стоимость владения (TCO) с учётом доработок и будущей поддержки, мы решили инвестировать в собственное решение. Это даёт нам главное преимущество — полный контроль над развитием платформы под специфику нашего производства. Как верно отметил @ildarz ниже, экономически этот путь оказался оправдан. +100 в карму ему за это!)
Фронтенд на реакте, а бэкенд на "корпоративной системы кадрового учета"... Захотели написать про свое техническое решение, но информация оказалась секретной?
И да, эксель изначально использовался не по назначению.
Можно в статье заменить Excel на Word, например, и смысл вообще не изменится, даже в мелочах править не придется.
Эх. Давно в 90-х, нам преподавали dBaseIV+, и делали простейшие задачи. Появилась идея сделать ячейки в которые можно заносить данные, а не писать код для каждой операции. Тогда компиляция занимала минут 5. Дома писал и компилировал на Поиске с доп модулями памяти и дисковода, минут 15 занимало. Успевал ужин приготовить. И если в конце компиляции выдавало ошибку, это была Беда. Но зато этот опыт воспитал быть внимательным.
Когда впервые увидел Excel через пару лет, узнал то что писал в студенчестве.
Замахиваться на Excel я бы не стал. На Google таблицы , ещё можно. Но до Excel вам со своим решением далековато (именно , до табличного процессора, коим Excel является).
Серьёзно, просто давайте набор встроенных функций смэтчим, или вот, на убой, а извольте предъявить свой VBA??? Давеча водил родственницу к психиатру , а у него там макросы накодены в полный рост, я через плечо глянул , там и формы и range обрабатывает, то есть реальный серьёзный обработчик ручками написан.
А у вас оно где???
База — минимум для допуска к работе. Сотрудник знает основы, может выполнять простые операции под контролем.
Стандарт — уверенное владение. Работает самостоятельно, может обучать новичков.
Эксперт — глубокие знания.
Что за изобретание велосипеда,
Джун, Мидл, Сеньер !
Личный кабинет для обычного работяги - правильное решение. Будет понимать и мотивироваться на развитие.
Для него же возможность электронного формирования различных заявлений, например на отпуск, отгул, обучение и т.д. в изначально в электронном виде и целевом формате.
Ведь сейчас нужно написать заявление на бумаге, по определенному стандарту. Его потом отсканируют в СЭД, создадут цепочку согласований...
И конечно о значимых целевых событиях уведомление на мобилу каждого работника. Например, заявление на .... утверждено/отклонено Ивановым, причина ... и т.д.
В фронте хотелось бы более обширную табличную визуализацию с произвольной фильтрацией.
Ну и на будущее, промтовое и даже голосовое управление подходящими задачами. Например, выбрать слесаря Иванова И.И., поставить его в смену 10.08.2025г. показать откорректированный график обучения....
Над текстом ржал примерно через абзац... такое ощущение что автор специально затролил СИБУР...что не абзац, то камень в сторону управленцев.
Больше орнул над цитатой:
Производство приходит к нам с проблемой или потребностью, а ИТ подключается как партнёр, который превращает методологию и практики бизнеса в работающий цифровой сервис.
Перевожу с бизнес языка на русский: "Как обычно какой-то большой начальник сгонял в Японию в командировку, насмотрелся там "заморских" фич, а по приезду захотел внедрить что-то типа пахожее, но поскольку "тямкалки" своей нехватило погрузится в вопрос и использовать готовый продукт - вызвал начальника IT и спустил на итшников геморрой: давайте делайте! На то вы и итшники! Те схватились за голову все бросили и начали заниматься этой дребеденью...попутно матеря этого начальника: "что б он по Япониям своим блин не катался"...
Не похоже на "привёз из Японии и спустил". В тексте прямо сказано, 4 года вручную обкатывали методологию в Excel, СТП, единые матрицы и только потом позвали ИТ, чтобы автоматизировать уже рабочий процесс
Вот прям 100% так и было.
Командировочный "увидел" что то полезное в японии, а не только саке жрал.
увидел, потому что на родном предприятии ему приходилось сталкиваться с проблемой. Иначе бы не увидел, есть такая узость восприятия, пока не достало - не видит.
привез как ноу - хау и долбаным итишникам объяснил как надо.
повод похвалиться на планерках как он в японии был.
учить итишников еще можно лет 5, на примере японии и хвалиться своей поездкой.
Вот эти 4 года меня поставили в тупик. Вся методология то как раз готова, надо только её автоматизировать! Ну и ещё: поскольку на разных заводах она немного отличается, нужно найти общий знаменатель, который бы всех устроил. И это работа для целой команды на 4 года?
Всё что вы описали как "сделали лучше" - на производстве работать не будет. В гос. структурах тоже.
Кейс живой. Видно, что ИТ пришло под методологию, а не наоборот. Так и должны рождаться внутренние продукты
А слона то и не приметили. Все эти "тесты" и "аттестации" - созданы в первую очередь для сокрытия некомпетентности руководства. Снизу доверху. И для прикрытия своих жоп.
Т.е. ребята такие:
Давайте в ячейки вместо данных вносить цвета
Ой, это ж потом никак толком не обработать!
Это крайне низкая культура проектирования. Причем тут эксель? В любой другой системе с таким же подходом будут подобные же и проблемы.
Свести их вместе, чтобы понять общую картину по компании? Это отдельная работа на несколько дней.
Так сделайте сотню разных сервисов с несовместимым хранением данных и попробуйте свести их вместе. Будут ровно те же проблемы.
Думаю, просто в проектирование средств автоматизации на эксель вложено условно 100к рублей, а в тож самое на новомодном стеке 1млн.
Да в этом плане есть много белее удобного инструментария. Но в плане введения этого инструмента у нас проблемы. Женщины и мужики работяги делают это в экселе потому что они уже знают как там работать. Если есть какая то дополнительная вкладка или не дай бог панель как то не так расположена. Они в жизни в ней не разберутся. Я работал на заводе там в эксель таблицах такие базы огромные. По 12 вкладок,60 000 строк, и все это сделано в 2008 году, все работают на разных версиях офиса, миллион неактивных ячеек но они прогружается. И все это грузится минут по 10 при запуске. Людям все равно это лучше чем перенести это в Access. Мы их 2 месяца пробовали переучить. Но никак.
Слабо пробовали. Говорю по своему опыту. Ну и не Access им нужен, а SQL Sever.
Тоесть вы для "60000 строк" людям хотели дать Access???
Да вы, батенька, знатный садист и изувер каких поискать еще нужно!
...Впрочем, всем тем кто предлагает Access нужно проходить в обязательном порядке медосведетельствование у психиатра...
Конечно, это же прямой конкурент продвинутых решений. На MS Access можно бесплатно сделать решения стоимостью сотни миллионов рублей. На Borland Delphi аналогично. Слышали про теневое ИТ?
Я очень рад, что эти работяги не смогли за 2 месяца перебраться из Excel в Access :))) Они наверное что-то подозревали, что это не тру-вей решение :)))....А этому господину который хотел их мигрировать было б неплохо какой-нибудь Postgress или MySQL поизучать что-ли :)
А интерфейс на чем делать? Это только MS Access все в одном - интерфейс и субд. Excel тоже часто так используется, потому что тянет огромные объёмы. Где делать интерфейс?
Если сравнить трудозатраты для интерфейса в Access и трудозатраты накидать мышкой форму в условном Builder C++ или том же Visual Studio.....то последние выигрывают с большим перевесом....а если есть минутка времени, две сигареты и чашка кофе, то можно и HTML страничку накидать, и даже в этом случае это будет проще чем делать что-то в Access.
Для человека с отсутствием профильного опыта это не так. Порог вхождения для Access несравнимо ниже, чем для любой связки "SQL сервер+клиентское приложение".
Ну так!!! Конечно! Полностью согласен, кухарка не должна заниматься базами данных, это как минимум должен быть человек с образованием понимающий для чего нужны базы данных и как их готовить. Если человек не знает как подойти к SQL, то за то что он пытается лезть в Access - ему нужно больно бить по рукам! (а тем более когда ведется разговор про "взрослые" БД в 60 тыс строк), это как если бы вам нужен нормальный двухэтажный дом, а вам предлагают сделать его из фанеры, соломы и немного глины ....как бы да, сделать-то можно (это будет и быстрее и дешевле), но очевидно заказчик не получит того результата, на который он расчитывает.
Все верно, строители и архитекторы должны заниматься стройкой, ИТ инженеры - ИТ, а хирурги должны лечить...и было бы много хуже если человек который отличный специалист по БД начал бы лечить вашего к примеру сына - думаю вам бы это совсем не понравилось.
А еще интересно, почему-то считается что капитан корабля, должен долго обучаться, только после этого он сможет рулить баркасом; хирургу - тоже нужно долго учиться, прежде чем его допустят до живых людей, всякие интернатуры и прочее; а вот в ИТ почему-то считается что если ты знаешь как установить винду - все ты можешь и базы данных писать и хостингом заниматься, и принтер починить, а в свободное время еще запустить почтовый серверок....
1. MS Access тянет такие тяжёлые файлы?
2. Может ли MS Access подключаться к единому корпоративному SQL Server?
И я не понял: Вы, я надеюсь, не рассчитывали на то, что люди будут сами себе на Access запросы писать?
Access - файловая СУБД, со всем их достоинствами и недостатками. Какие файлы она "тянет", будет определяться дисковой подсистемой хранилища базы, сеткой, CPU/памятью клиента и написанными запросами. Для обсуждаемых объемов я не вижу серьезной проблемы. Дополнительно подключаться может к любым внешним источникам данных, доступ к которым возможен через ODBC. База на MS SQL, интерфейс на Access - в принципе тоже рабочий сценарий.
И да, киллер-фича именно Access и прямых аналогов - "люди сами себе могут писать запросы". Там RAD среда с очень низким порогом вхождения, писать напрямую на SQL не обязательно, можно просто в визуальном конструкторе накидать формочек с полями (общая сложность плюс-минус та же, как когда вы из Экселя подключаетесь к внешнему источнику и не просто данные тянете, а еще и указываете способы их обработки). Для среднестатистического офисного работника это проблема, а для приличного инженера или экономиста, равно как и обычного эникейщика - далеко не всегда.
По факту сейчас это очень нишевое решение, потому что если компания работает с данными, с которыми не справляется Эксель, у нее уже могут быть и свои учетные системы, где похожие задачи решаются. Но право на существование вполне имеет.
Я таких приличных инженеров и экономистов среди не-программистов еще не встречал. Мне и самому несравненно легче написать скриптик на уже известном мне Питоне с Пандас, чем осваивать еще одну "среду с очень низким порогом вхождения".
А я встречал. Да и сам в далеком прошлом делал для мелкой компании на базе Access аналог CRM, собственно айтишного опыта не имея вообще, а из программирования будучи знакомым только с научными расчетами на Turbo Pаscal. Ничего, с десяток лет проработали на нем, потом уж не знаю что с ними было. А сейчас основы SQL даже напрямую кое-где в вузовские программы входят на специальностях, которые не айтишные, но соприкасаются, так что такой выпускник, если он действительно учился, не только формочки накидать сможет, но и вменяемые запросы ручками написать при минимальной помощи гугла и дипсика. И это вполне себе нынешняя обыденность, у меня вон дочка так делает.
А если вам проще на питоне, так и пожалуйста. Но я не понимаю, в чем суть ваших возражений? "Я не встречал, я не умею"? Это не очень продуктивно, на мой взгляд.
Непрограммист, любой человек может записать свои действия в макрос в Excel, например, открытие файлов, поиск. Остаётся только немного поправить код. В Access чуть сложнее. Как сейчас экономисту автоматизировать свою работу на Linux, если никаких сторонних программ не установить? Например, нужно обработать тысячу файлов xlsx или docx, найти там что-то по ключевым словам с учетом объединённых ячеек и положить в другой файл?
Есть кое-что получше, чем Excel