Спасибо, полезное видео. Главная мысль спикера — перестать сохранять информацию в файлах, пересылая их разными способами (CRM, СЭД, почта ...) и начать уже хранить данные в базах данных, где к ним есть доступ из процессов. Полностью с ним согласен и мы делаем то же самое. Тут отличия только в терминах: он «документом» называет файл, а «карточкой документа» — набор полей, с инфой из БД. Я документом называю как раз карточку документа (набор полей, то что в сайдбаре), а файл я называю файлом. У нас все крутится не вокруг файла, а как раз вокруг процесса, который мы описываем в сайдбаре (то, что называем формой документа). Просто у нас метод описания процесса отличается от BPM нотации
Тут ведь дело не в серьезности. Если скрипты решают задачи пользователей, почему бы и нет. Насколько знаю, даже в сбербанке в свое время (не знаю как сейчас) достаточно сложные процессы автоматизировали как раз на VBA. Разные компании на разных этапах цифровизации: редко происходит переход от бумажного документооборота сразу к ERP, минуя сетевые папки, сканы, документооборот по электронной почте, табличные редакторы, скрипты и облачные реестры.
Все попытки на моей памяти «сделать программирование для непрограммистов» — провалились.
Да кажется наоборот, nocode платформы неплохо растут. Да и те же Excel и Гугл таблицы очень много пользы приносят, просто все как то привыкли и не замечают уже.
А вообще, согласен, у каждого инструмента есть свой предел. Можно начать автоматизировать с таких простых продуктов, обкатать логику, самим заказчикам разобраться в своих же процессах, потом переходить на более комплексные решения
Конкретно в описанном бизнес-процессе этот момент не прописан, чтобы не усложнять. А вообще можно дать каждому согласующему перевести не только в статус Согласовано, но и обратно в Открыто. Там многое зависит от конкретного процесса: одним при несогласовании нужно откатить на один шаг назад, другим в самое начало цепочки и т.д.
Я бы сказал, что подобным инструментом можно организовать типовую СЭД, таск-трекер, хелп деск, управление закупками и другие (не имеющие устоявшегося названия) системы коллективной работы. Наверняка есть процессы, которые организовать тут будет не удобно. Если знаете примеры таких процессов, поделитесь
Excel действительно многое позволяет реализовать, не раз видел, как заказчику, не умеющему (или не желающему) в нем работать продают почти то же самое за гораздо большие деньги. И если посмотреть, как автоматизируют свою работу IT компании и производственные, то первый часто пользуются какими-то конструкторами, nocode решениями, гугл таблицами, эйртейбл, а вторые готовы отдать много денег за создание какого-нибудь реестра в облаке. У всех своя специализация и все по своему правы.
Конечно, не все. Но и не так мало, как может сначала показаться. Тут мне очень нравится подход вот этой команды: planfix.ru/ideologiya
Наблюдал за ними еще на старте, 10 лет назад и с тех пор все еще не разочаровался
> Я не вижу ничего автоматизированного в этом документе
Согласен) Если разбить процесс цифровизации на этапы, то сначала нужно дать пользователям систему, в которой каждому виду информации будет свое место (пусть даже заносить ее вручную). На этом этапе можно обкатать структуру БД и логику процессов. А затем уже автоматизировать работу. Если сразу накрутить автоматизацию, то юзерам, еще не понявшим общую структуру и типы сущностей, работа системы кажется непредсказуемой (они даже не могут толком понять, что не так и что вообще происходит)
Это личное мнение и многое зависит от сферы деятельности и компании. Например в маркетинге или банковом секторе информационные потоки уже оцифрованы, а вот в строительных компаниях (наши заказчики) первый этап еще не пройден.
Про финмодель: пока ее главный потребитель — гендиректор, который прилетает на объект не часто и смотрит отчеты раз в месяц, так как объектов много и они в разных городах. Мы сфокусированы на том, чтобы предоставить ему интерфейс, в котором он может быстро оценить ход проектов для управления бизнесом. Убедить его, что это полезно. Я пытался сделать так, чтобы и РП нашли в этом свою пользу, они могут быстро получить информацию по актам выполнения и оплатам. Но в целом, они никак не замотивированы заниматься таким планированием, т.к. это никак не связано с их KPI. В перспективе контроль, конечно, должен носить непрерывный характер, а не раз в месяц, Но это когда мы выстроим все процессы и сформулируем требования к их участникам. Такая вот методика внедрения в большой компании, в которой много действующих лиц и отделов, и у всех свои интересы)
Интеграцию со Skethup можно сделать напрямую, когда 1 объект в модели будет соответствовать одному квадратику в визуализации. И в зависимости от значения в визуализации объект в модели будет менять цвет, видимость или прозрачность. А можно сложнее, когда значения группы квадратиков (например целый этаж) как-то обобщаются и передаются в модель, где один объект представляет тот самый этаж (то же самое для интеграции с WBS в проджекте, ведь она может быть не такой детальной, как визуализация).
Принцип может быть такой:
1. В визуализации нужно каждому элементу присвоить его идентификатор. В таблицах это очень просто, автозаполнением можно быстро проставить в каждую клетку [этаж+номер квартиры] или что-то подобное.
2. В 3d-модели тоже нужно создать соответствующие элементы (в Sketshup легко создаются массивы однотипных элементов) и присвоить те же идентификаторы, что и в таблице (вот это не представляю как сделать, не погружался в вопрос).
3. Дальше дело за малым: скрипт в таблице превращает данные о элементах визуализации в какой-то стандартный вид (текст, JSON, что придумаете), а скрипт в Sketchup (там есть Ruby) принимает эту инфу и меняет свойства соответствующих элементов.
Но это все просто мысли, мы их не увязывали, не было такой задачи. Если взглянуть шире, может оказаться «зачем это все?», ведь 3d модель на самом деле не очень информативна и даже не очень удобна (хоть и эффектна). Она скорей для тех, кто совсем не в деталях и кого хочется побаловать такими изысками (самые топ-топ-менеджеры, акционеры, потенциальные заказчики). А для таких случаев раз в пару месяцев проще вручную модель покрасить
Тут ведь дело не в серьезности. Если скрипты решают задачи пользователей, почему бы и нет. Насколько знаю, даже в сбербанке в свое время (не знаю как сейчас) достаточно сложные процессы автоматизировали как раз на VBA. Разные компании на разных этапах цифровизации: редко происходит переход от бумажного документооборота сразу к ERP, минуя сетевые папки, сканы, документооборот по электронной почте, табличные редакторы, скрипты и облачные реестры.
Да кажется наоборот, nocode платформы неплохо растут. Да и те же Excel и Гугл таблицы очень много пользы приносят, просто все как то привыкли и не замечают уже.
А вообще, согласен, у каждого инструмента есть свой предел. Можно начать автоматизировать с таких простых продуктов, обкатать логику, самим заказчикам разобраться в своих же процессах, потом переходить на более комплексные решения
Excel действительно многое позволяет реализовать, не раз видел, как заказчику, не умеющему (или не желающему) в нем работать продают почти то же самое за гораздо большие деньги. И если посмотреть, как автоматизируют свою работу IT компании и производственные, то первый часто пользуются какими-то конструкторами, nocode решениями, гугл таблицами, эйртейбл, а вторые готовы отдать много денег за создание какого-нибудь реестра в облаке. У всех своя специализация и все по своему правы.
Статью почитаю, спасибо!
Наблюдал за ними еще на старте, 10 лет назад и с тех пор все еще не разочаровался
Согласен) Если разбить процесс цифровизации на этапы, то сначала нужно дать пользователям систему, в которой каждому виду информации будет свое место (пусть даже заносить ее вручную). На этом этапе можно обкатать структуру БД и логику процессов. А затем уже автоматизировать работу. Если сразу накрутить автоматизацию, то юзерам, еще не понявшим общую структуру и типы сущностей, работа системы кажется непредсказуемой (они даже не могут толком понять, что не так и что вообще происходит)
Это личное мнение и многое зависит от сферы деятельности и компании. Например в маркетинге или банковом секторе информационные потоки уже оцифрованы, а вот в строительных компаниях (наши заказчики) первый этап еще не пройден.
Хм, ни разу не возникало дилеммы. Я всегда только один голос слышу)
Принцип может быть такой:
1. В визуализации нужно каждому элементу присвоить его идентификатор. В таблицах это очень просто, автозаполнением можно быстро проставить в каждую клетку [этаж+номер квартиры] или что-то подобное.
2. В 3d-модели тоже нужно создать соответствующие элементы (в Sketshup легко создаются массивы однотипных элементов) и присвоить те же идентификаторы, что и в таблице (вот это не представляю как сделать, не погружался в вопрос).
3. Дальше дело за малым: скрипт в таблице превращает данные о элементах визуализации в какой-то стандартный вид (текст, JSON, что придумаете), а скрипт в Sketchup (там есть Ruby) принимает эту инфу и меняет свойства соответствующих элементов.
Но это все просто мысли, мы их не увязывали, не было такой задачи. Если взглянуть шире, может оказаться «зачем это все?», ведь 3d модель на самом деле не очень информативна и даже не очень удобна (хоть и эффектна). Она скорей для тех, кто совсем не в деталях и кого хочется побаловать такими изысками (самые топ-топ-менеджеры, акционеры, потенциальные заказчики). А для таких случаев раз в пару месяцев проще вручную модель покрасить