А что делать, если оценки по разным шкалам разнятся?
Например — по шкале зарплаты скачки будут, но раз в 5 лет.
А по шкале производительности то просадка, то повышение.
А по разнообразию занятий тоже скачки, но чаще.
То есть если усреднить график ЗП, то человек — фрезеровщик, у него ЗП в среднем за годы не меняется, но по рынку, например, очень высокая.
Если усреднить график производительности — то в среднем по годам производительность то стабильно растет (меняется профиль деятельности, работа интересная, задачи сложные), то падает (сложные задачи сделаны, период отдыха да анализа обстановки вокруг — что бы еще такого начать творить).
Если по разнообразию занятий — аналогично графику производительности, человек то большой проект делает и много смежных сфер начинает изучать, то заканчивает проект и статейки на хабре почитывает до следующего большого этапа.
Вот как такого оценить? Комплексно интеллектуально человек растет — у него с годами растет багаж знаний, опыта, он более интересен собеседникам и хранит бОльший опыт решения проблем. Но в зарплате он не растет. А иногда и падает, например — ушел с работы на другую, там ЗП меньше, но куда более интересные задачи. И ЗП опять постепенно растет до прежнего уровня. Но ему и на жизнь хватает (машина, дом, поездки) и мозг не костенеет.
Сколько аэропортов в Европейской части России и сколько — в Европе на той же площади? В России, как правило, выбирать приходится между автомобилем и поездом, нежели самолетом и поездом.
Судя по всему, этот момент я пропустил. В самом начале статьи было упомянуто про бэкапы в том плане, что можно не архивировать отдельные файловые группы, верно, но, получается, они будут всегда подключены. А как происходит attach такой базы данных? Все файлы из всех файловых групп нужно выбирать вручную при подключении базы?
Интересная штука. А можно ли это применить для того, чтобы хранить в секциях данные по годам (для десятков таблиц) и отключать/подключать секции с ненужными годами при необходимости? Скажем, отключить файловую группу с секцией за 2018й год, заархивировать и убрать с глаз долой. Потом, если возникает необходимость посмотреть архивы за 2018й, просто подключить секции и пользоваться данными. Потребность отпала — отключил.
Такое в принципе реализуемо? Насколько это геморно и можно ли автоматизировать процесс? И вообще насколько механизм для этого предназначен?
Любое типовое решение для производства НЕ работает так, как надо просто потому, что каждое производство уникально. И даже промежуточные модули и даже дописанные ПОД ВАС не будут работать исходя из уникальности каждого производства.
1С взлетело чисто на бухгалтерии, на том, что весь бухучет регламентирован и описан по шажочкам (и то есть споры по применению номеров счетов, как понял). Производство не регламентируешь и ВСЕГДА надо писать ПО под существующий бизнес-процесс, а не пробовать впихнуть что-то в прокрустово ложе фантазии разработчика типового решения.
У нас на пищевом производстве ИТРП сдохло за пару лет. Проходили Lipro, ИТРП, в итоге десять лет самописное решение тащит все производство. А бухгалтерия свои отчеты делает в 1С по данным, сложенным в кучку из оперучета самописного решения.
Как человек, работающий внутри завода в ИТ, могу объяснить.
Есть два типа заводов:
1) созданные для работы с бумажными журналами и документацией. Как правило, это заводы, запущенные до середины нулевых;
2) те заводы, при создании которых упор делался изначально на ИТ-системы. Бумажных доков почти нет, все контролирует система.
В первом варианте завод может работать без ИТ-системы. Криво, косо, но может. Где-то не будут выполняться сроки, где-то не будет контроля качества, но оно будет выдавать продукцию. ИТ-система дает кучу точек контроля и много информации для оценки качества, дает возможность ускорить производство. То есть — это средство оптимизации.
Во втором варианте завод просто не будет работать, т.к. сотрудники в массе не особо владеют ситуацией. Это, например, автоматизированный завод Черкизона — при желании руками что-то можно делать, но практически нереально работать эффективно.
Большинство заводов — первый тип. На работающую человеческую систему наложили ИТ-систему и они зачастую не органично срощены, а сосуществуют и от степени конфликта в их сосуществовании зависит количество ненависти между теми, кто поддерживает и ведет эту систему и остальными сотрудниками.
Читая эту статью и заранее даже зная о том, что не получилось, искренне болел за автора в надежде, что всё срастется ) это как Войну Бесконечности пересматривать — знаешь, что в конце будет печально, но болеешь за положительный результат))
Не только пищепром. Всё, что связано с химическими преобразованиями — туда же. Производство красок, специй, лекарств. Мехобработка, запчасти — это вообще самое простое, что только может быть. Склад может лежать годами, сроки годности огромные, сложности возникают только тогда, когда заказ превышает производительность и её пытаются повысить путем оптимизации, а не наращивания мощностей.
nmivan, тут на Хабре с Вами не меньше половины согласится, это головная боль современности. Проблема-то в подходах к работе.
Привилегированное положение 1С в том, что моду задает разработчик платформы, то есть головная компания. Весь фреймворк, доступные возможности разрабатываются ими. Что дали — тем пользуйся. Делаешь коммерческую конфигурацию — изволь сертифицировать по жестким правилам. Отсюда растут ноги у кучи ограничений с расширением конфигураций. Я не 1С-ник, но от наших ребят наслушался много. Правда, говорят, в восьмерке сейчас расширять существующие формы стало легче, но тут уже хз.
Но вот опять же, 1С оперирует терминами и понятими бухучета, в основном.
Разработчик бизнес-приложения оперирует чуть большим набором понятий. В базе те же заказы, ордера и движения, но для оформления этих движений нужно вводить дополнительные моменты. Например, в том же интернет-магазине есть скидки и промоакции. В форме заказа надо добавить учет скидок, добавить учет промокода, провести их каким-то образом, применить скидку по цене, добавить доп. товары к заказу и так далее. К объектам «номенклатура» и «движение» прибавляется «акция», добавляется сложная связка между «акция» и «номенклатура» с условием акции… Вроде всё несложно, но, чтобы избежать нагромождения костылей, начинаешь думать про применение паттернов. Какой-никакой интерфейс, фабрика объектов и так далее (зависит от степени извращенности автора).
Двигаемся дальше, находим новые объекты и сложность схемы растет еще больше. Приходится применять новые архитектурные решения. Некоторые архитектурные решения сложноприменимы в рамках одного языка — уткнулись в ограничение.
Если же готовая архитектура есть, но она плохо расширяема и не подходит — та же беда. В итоге скатываемся к тому, что лучше использовать что-то гибкое и расширяемое, то есть берем другую платформу языка.
Ок, ладно, почему бы не сделать бизнес-решение на каком-то гибком языке? Ок, давайте выберем… ну, например, c#.
1. Строим архитектуру, делаем крутое решение в коде. Оно даже расширяемое, замечательно!
2. И тут здрасьте — мы строили его на asp.net mvc, а сейчас в тренде asp.net core. Вроде бы ничего особенного, но разработчики, которые ищут себе сейчас бизнес-продукт, хотят на core. Ок, ладно, мы переписываем основу решения, делаем возможность запускать его на asp.net mvc и asp.net core. Супер!
3. Теперь к нам приходят клиенты и говорят — знаете, мы ваше решение взяли, но наши крутые современные итшники говорят, что у нас какая-то там морда на каком-то реакторе, а у вас старый жуквэри и переносить наш модный интерфейс, в который мы бухнули кучу бабла, на старые рельсы нерентабельно. Хорошо… садимся и делаем так, чтобы клиент мог переработать интерфейс на любую фронтенд-платформу — react, vue, node, angular, старый-добрый html+jquery и так далее. Ну и дописываем еще WebApi, потому что какой еще модный фронтенд без вебапи?
4. Всё, у нас гибкое масштабируемое решение, можно переделать бизнес-логику, расширить, можно сменить морду… мы потратили пять лет и 100500тыщмильёнов на разработку. Нам бы еще отбить эти траты? Цена на внедрение потихоньку растет :) Мелкий бизнес отвалился, средний думает, крупный давно внедрил свои велосипеды. Наше типовое решение мелкому бизнесу неудобно, надо дорабатывать, но дороговато. Средний бизнес на типовое решение согласится со скрипом, если найдутся грамотные «впариватели». А крупный где-то там наверху лениво дернет ухом и дальше будет разрабатывать чекблойн-технологии.
P.S. Я еще вот чего не понимаю — как вообще можно разрабатывать бизнес-решение в отрыве от бизнеса? Это как игровой движок разрабатывать в отрыве от игр. А как понять, что именно в геймдизайне применять придется-то? Ну, можно сделать ту часть движка, которая отвечает за графические эффекты, физические эффекты, а всё остальное — модели, взаимодействие их друг с другом, всю «бизнес-логику игры» придется писать под себя на конкретную игровую механику.
Вот если ты игру разрабатываешь и делаешь под неё движок — отлично. Все моменты, которые там используются, реализуются под себя, в итоге получается какое-то готовое решение. И вот его и можно и нужно тиражировать, предварительно чуть универсализировав!
Скажите мне, сажал ли кто-то команду разработчиков MES-части в ERP на существующее производство, чтобы они написали то, что реально покрыло все процессы на производстве и упростило их ведение? То есть не по чьему-то универсальному ТЗ что-то написали как платформу, а реально внедрили полностью? А потом из этого попытались сделать универсальный продукт. Да ничего у них не вышло бы. А если бы и вышло, то это был бы такой чудовищный монстр, что его только изучать надо несколько лет.
У нас вот есть MES-система, я её вдоль и поперек знаю и понимаю, что её можно при желании стиражировать, но её писали мы сами и под нас, то есть она реально рабочая и учитывающая все моменты. И перестроить её можно, чтобы вообще универсальной стала. Но как бы мы смогли такую сделать, не работай с производством — ума не приложу. Тут никаких ТЗ не хватит.
Бизнес-логика не расширяется со стороны пользователя.
Как-то нехорошо звучит. Но ведь наш процесс может отличаться от заложенного в системе. Это же не бухучет, мы можем работать как вздумается. Это поведение нельзя изменить?
Например — по шкале зарплаты скачки будут, но раз в 5 лет.
А по шкале производительности то просадка, то повышение.
А по разнообразию занятий тоже скачки, но чаще.
То есть если усреднить график ЗП, то человек — фрезеровщик, у него ЗП в среднем за годы не меняется, но по рынку, например, очень высокая.
Если усреднить график производительности — то в среднем по годам производительность то стабильно растет (меняется профиль деятельности, работа интересная, задачи сложные), то падает (сложные задачи сделаны, период отдыха да анализа обстановки вокруг — что бы еще такого начать творить).
Если по разнообразию занятий — аналогично графику производительности, человек то большой проект делает и много смежных сфер начинает изучать, то заканчивает проект и статейки на хабре почитывает до следующего большого этапа.
Вот как такого оценить? Комплексно интеллектуально человек растет — у него с годами растет багаж знаний, опыта, он более интересен собеседникам и хранит бОльший опыт решения проблем. Но в зарплате он не растет. А иногда и падает, например — ушел с работы на другую, там ЗП меньше, но куда более интересные задачи. И ЗП опять постепенно растет до прежнего уровня. Но ему и на жизнь хватает (машина, дом, поездки) и мозг не костенеет.
Такое в принципе реализуемо? Насколько это геморно и можно ли автоматизировать процесс? И вообще насколько механизм для этого предназначен?
Зашел зарегистрироваться — там от 60руб/ч начинается.
1С взлетело чисто на бухгалтерии, на том, что весь бухучет регламентирован и описан по шажочкам (и то есть споры по применению номеров счетов, как понял). Производство не регламентируешь и ВСЕГДА надо писать ПО под существующий бизнес-процесс, а не пробовать впихнуть что-то в прокрустово ложе фантазии разработчика типового решения.
Это не реклама, просто натыкался на них на хабре.
Есть два типа заводов:
1) созданные для работы с бумажными журналами и документацией. Как правило, это заводы, запущенные до середины нулевых;
2) те заводы, при создании которых упор делался изначально на ИТ-системы. Бумажных доков почти нет, все контролирует система.
В первом варианте завод может работать без ИТ-системы. Криво, косо, но может. Где-то не будут выполняться сроки, где-то не будет контроля качества, но оно будет выдавать продукцию. ИТ-система дает кучу точек контроля и много информации для оценки качества, дает возможность ускорить производство. То есть — это средство оптимизации.
Во втором варианте завод просто не будет работать, т.к. сотрудники в массе не особо владеют ситуацией. Это, например, автоматизированный завод Черкизона — при желании руками что-то можно делать, но практически нереально работать эффективно.
Большинство заводов — первый тип. На работающую человеческую систему наложили ИТ-систему и они зачастую не органично срощены, а сосуществуют и от степени конфликта в их сосуществовании зависит количество ненависти между теми, кто поддерживает и ведет эту систему и остальными сотрудниками.
Дак это не мораль, а вполне очевидная истина.
Иван, вы бы свой же термин "суррогаты" применили про плохого программистов) https://m.habr.com/ru/post/344844/
Привилегированное положение 1С в том, что моду задает разработчик платформы, то есть головная компания. Весь фреймворк, доступные возможности разрабатываются ими. Что дали — тем пользуйся. Делаешь коммерческую конфигурацию — изволь сертифицировать по жестким правилам. Отсюда растут ноги у кучи ограничений с расширением конфигураций. Я не 1С-ник, но от наших ребят наслушался много. Правда, говорят, в восьмерке сейчас расширять существующие формы стало легче, но тут уже хз.
Но вот опять же, 1С оперирует терминами и понятими бухучета, в основном.
Разработчик бизнес-приложения оперирует чуть большим набором понятий. В базе те же заказы, ордера и движения, но для оформления этих движений нужно вводить дополнительные моменты. Например, в том же интернет-магазине есть скидки и промоакции. В форме заказа надо добавить учет скидок, добавить учет промокода, провести их каким-то образом, применить скидку по цене, добавить доп. товары к заказу и так далее. К объектам «номенклатура» и «движение» прибавляется «акция», добавляется сложная связка между «акция» и «номенклатура» с условием акции… Вроде всё несложно, но, чтобы избежать нагромождения костылей, начинаешь думать про применение паттернов. Какой-никакой интерфейс, фабрика объектов и так далее (зависит от степени извращенности автора).
Двигаемся дальше, находим новые объекты и сложность схемы растет еще больше. Приходится применять новые архитектурные решения. Некоторые архитектурные решения сложноприменимы в рамках одного языка — уткнулись в ограничение.
Если же готовая архитектура есть, но она плохо расширяема и не подходит — та же беда. В итоге скатываемся к тому, что лучше использовать что-то гибкое и расширяемое, то есть берем другую платформу языка.
Ок, ладно, почему бы не сделать бизнес-решение на каком-то гибком языке? Ок, давайте выберем… ну, например, c#.
1. Строим архитектуру, делаем крутое решение в коде. Оно даже расширяемое, замечательно!
2. И тут здрасьте — мы строили его на asp.net mvc, а сейчас в тренде asp.net core. Вроде бы ничего особенного, но разработчики, которые ищут себе сейчас бизнес-продукт, хотят на core. Ок, ладно, мы переписываем основу решения, делаем возможность запускать его на asp.net mvc и asp.net core. Супер!
3. Теперь к нам приходят клиенты и говорят — знаете, мы ваше решение взяли, но наши крутые современные итшники говорят, что у нас какая-то там морда на каком-то реакторе, а у вас старый жуквэри и переносить наш модный интерфейс, в который мы бухнули кучу бабла, на старые рельсы нерентабельно. Хорошо… садимся и делаем так, чтобы клиент мог переработать интерфейс на любую фронтенд-платформу — react, vue, node, angular, старый-добрый html+jquery и так далее. Ну и дописываем еще WebApi, потому что какой еще модный фронтенд без вебапи?
4. Всё, у нас гибкое масштабируемое решение, можно переделать бизнес-логику, расширить, можно сменить морду… мы потратили пять лет и 100500тыщмильёнов на разработку. Нам бы еще отбить эти траты? Цена на внедрение потихоньку растет :) Мелкий бизнес отвалился, средний думает, крупный давно внедрил свои велосипеды. Наше типовое решение мелкому бизнесу неудобно, надо дорабатывать, но дороговато. Средний бизнес на типовое решение согласится со скрипом, если найдутся грамотные «впариватели». А крупный где-то там наверху лениво дернет ухом и дальше будет разрабатывать чекблойн-технологии.
P.S. Я еще вот чего не понимаю — как вообще можно разрабатывать бизнес-решение в отрыве от бизнеса? Это как игровой движок разрабатывать в отрыве от игр. А как понять, что именно в геймдизайне применять придется-то? Ну, можно сделать ту часть движка, которая отвечает за графические эффекты, физические эффекты, а всё остальное — модели, взаимодействие их друг с другом, всю «бизнес-логику игры» придется писать под себя на конкретную игровую механику.
Вот если ты игру разрабатываешь и делаешь под неё движок — отлично. Все моменты, которые там используются, реализуются под себя, в итоге получается какое-то готовое решение. И вот его и можно и нужно тиражировать, предварительно чуть универсализировав!
Скажите мне, сажал ли кто-то команду разработчиков MES-части в ERP на существующее производство, чтобы они написали то, что реально покрыло все процессы на производстве и упростило их ведение? То есть не по чьему-то универсальному ТЗ что-то написали как платформу, а реально внедрили полностью? А потом из этого попытались сделать универсальный продукт. Да ничего у них не вышло бы. А если бы и вышло, то это был бы такой чудовищный монстр, что его только изучать надо несколько лет.
У нас вот есть MES-система, я её вдоль и поперек знаю и понимаю, что её можно при желании стиражировать, но её писали мы сами и под нас, то есть она реально рабочая и учитывающая все моменты. И перестроить её можно, чтобы вообще универсальной стала. Но как бы мы смогли такую сделать, не работай с производством — ума не приложу. Тут никаких ТЗ не хватит.
Чёрт! Шеф, валим… :)
Как-то нехорошо звучит. Но ведь наш процесс может отличаться от заложенного в системе. Это же не бухучет, мы можем работать как вздумается. Это поведение нельзя изменить?