Составление отчетов, аналитических записок, выдача статистических данных для оперативного управления и т.п. — головная боль и кошмар любого заведующего ОМО, который ведет бумажный учет. Попробуйте быстро посчитать, например, сколько инвалидов, страдающих гипертонией, прикреплено к поликлинике или какова средняя длительность больничного листа и процент госпитализации по пневмониям за последние три месяца? Тем более что информация обычно нужна уже "вчера"... Единственный путь избавиться от этого кошмара — перейти от бумажного учета к компьютерному.
Кажется, что это просто... Любая поисковая система на запрос "Автоматизация медицины" выдаст несколько сотен тысяч ссылок — иди по самой понравившейся и пользуйся! Однако, даже при самом поверхностном анализе того, что предлагается на современном рынке автоматизации, на первый план выходят несколько достаточно сложных и трудноразрешимых для малобюджетного медицинского учреждения (а таковых в современной России большинство) проблем.
Первая проблема в том, что большая часть продуктов, представленных на рынке автоматизации (примерно 85%) — авторские разработки на различных СУБД с закрытыми исходными кодами интерфейсов и баз данных. Приобретая подобный продукт, вы оказываетесь намертво привязанными к разработчику. И если, не дай бог, с разработчиком что-нибудь случится или вас перестанет устраивать его сервис, либо цены, продукт смело можно выбрасывать, потому как внести какие-то изменения в продукт самостоятельно вы не сможете. Имеет смысл покупать только продукты с открытым исходным кодом и оговоркой в лицензионном соглашении, что вы имеете право вносить свои изменения в продукт. При этом достаточно большое значение имеет платформа, на которой построено решение, ведь нанять программиста на "1С" проще и дешевле, чем на «Oracle» или «Delphi».
Следующая проблема, с которой вы неизбежно столкнетесь — недостаточность вашей материальной базы для эффективного построения автоматизированного учета. Практически все программы автоматизации, предлагаемые сегодня на рынке, рассчитаны на глобальную автоматизацию, то есть, у вас должны быть компьютеризированы все рабочие места врачей + все параклинические кабинеты + три-пять рабочих мест в регистратуре + с десяток вспомогательных рабочих мест (отделение статистики, администрация и прочее подобное). Итого шестьдесят-восемьдесят компьютеризированных рабочих мест для стандартной территориальной поликлиники (при самом оптимистичном раскладе). А куда податься «бедному крестьянину» с имеющимся на сегодняшний день десятком маломощных и зачастую устаревших компьютеров? Приобрести недостающее «железо»? Прикинем... Шестьдесят комплектов «системный блок + широкоформатный монитор (23') + принтер с дуплексной печатью» (минимальная рабочая конфигурация) обойдутся в два миллиона рублей по самым минимальным прикидкам. Сюда же приплюсуем расходы по организации локальной сети с сервером, который по минимуму потянет всю эту сеть, — это примерно пять-семь миллионов. Всего выходит семь-девять миллионов рублей одномоментно для обычной территориальной поликлиники. Выбить такие деньги из местного департамента здравоохранения? Нереально... Придется обходиться тем, что имеется, и расширять сеть постепенно. При этом список возможных программных решений съёживается практически до нуля.
Очередная проблема, с которой вам придется иметь дело — отсутствие многих вещей, необходимых для повседневной текущей работы практического здравоохранения. При внимательном изучении программ, представленных на рынке, возникает впечатление, что к их написанию привлекался кто угодно: юристы, экономисты, ИТ-специалисты, администраторы, страховщики, но только не практикующие врачи. Простейший пример: по правилам учета заболеваемости «Статистический талон для регистрации заключительных (уточненных) диагнозов» - Ф. 025-2/у на хронические заболевания подается только раз в году, при первой явке пациента с таким диагнозом. Повторная подача талона на уже имеющееся хроническое заболевание является недопустимой. Ни в одной из исследованных программ автоматизации не предусмотрен механизм предотвращения ввода дублирующего статистического талона! Мало того, ни в одной программе не предусмотрено механизмов поиска дублирующихся статистических талонов, что делает статистику учета заболеваемости заведомо недостоверной. Такая же ситуация и в отношении многих других «мелочей», необходимых в текущей работе практикующего врача. Получается весьма нерадостная картинка: либо вам придется пользоваться заведомо недостоверными или не полными сведениями, либо платить достаточно приличные деньги за доработку уже купленной системы учета. Грустно, господа...
Но! Не так грустно, как кажется на первый взгляд. Можно пойти несколькими путями. Например, если у вас есть пять-десять компьютеров, связанных в какую-никакую сеть, и возможность выделить на автоматизацию полмиллиона-миллион рублей, можно обратиться в какую-нибудь фирму, занимающуюся автоматизацией на платформе «1С», и заказать там конфигурацию конкретно под ваши нужды. При этом нужно быть готовым к тому, что написание конфигурации и ее отладка займет порядка шести-восьми месяцев и в дальнейшем придется заниматься еще и внесением поправок в уже написанное. Да, еще учтите, что постановка задач для написания конфигурации — дело далеко не простое. Проблема в том, что вы и программист говорите на разных языках и то, что вам кажется само собой разумеющимся, для программиста далеко не факт. Так что если вы не уточните абсолютно все, вплоть до каждого нажатия любой клавиши, то рискуете получить в итоге совсем не то, что ожидали. А переделывать придется опять же за дополнительные деньги.
Можно пойти тем же путем, которым пошли мы четыре года назад: нанять программиста на «1С» на аутсорсинге (это обойдется совсем недорого), который будет писать конфигурацию в соответствии с поставленными вами задачами. Тогда года через два-три как минимум вы получите что-то, более-менее отвечающее вашим потребностям. Правда вам не раз придется «пройтись по граблям», на которые уже неоднократно наступали другие, но от этого никуда не денешься.
Данный материал был написан почти четыре года назад, но по различным причинам не публиковался. Самое интересное, что с момента написания (за прошедших четыре года) не изменилось ничего! Ситуация только ухудшилась. Только не нужно мне говорить про бурное развитие медицинских информационных систем типа ЕМИАС и ЕГИСЗ. Они страдают ровно теми же недостатками, что и все остальные и заточены больше на маркетинговые вещи и обслуживание пациентов, а не на облегчение и упрощение работы врача. Для практического врача они не то что не облегчают работу, но скорее усложняют и ухудшают условия, в которых приходится работать. Мало того, они внедряются силком, приказами сверху, не глядя на уже имеющиеся в ЛПУ системы учета, зачастую с потерей многолетних данных, уже в них накопленных и препятствуя созданию своих систем, более удобных для работы.
Нужно отметить еще один момент, на который почему-то внимание почти не обращается. Это зарубежные «санкции». Например, любая система, построенная на Оракл (американская фирма) может оказаться в очень интересном положении, если компании «Oracle» придет в голову заявить, что они вынуждены подчиниться «санкциям» и отозвать лицензии у российских компаний. В том, что у «Oracle» имеются закладки, способные обрушить базы, разработанные на их платформе, я абсолютно уверен.
Комментарии
Мы сейчас всю документацию ведём в Р-МИСе, при этом параллельно статистики всю информацию дублируют в старой ещё досовской программе разработанной в 90е. ЗАЧЕМ вся эта работа не понимаю. Р-МИС поставлен ростелекомом, имбецильная организация, техподдержка хлам, пока добьёшься изменений, месяцы проходят. при этом ВСЁ дублируется врачами в бумажном варианте, зачем, если есть всё в компьютере, нужно - распечатали. Короче работы стало больше, а толку ноль. В какую ординаторскую ни зайдёшь - все сидят за компами, и печатают, печатают, печатают. Периодически тормозит, виснет, бывает сутками не работает. Короче, с большим скрипом идёт, как всегда в России через задний проход. Хотя задумка правильная, вся документация в компе, больной выписан - распечатали, сложили в архив.
есть нормативка (законы и постановления) про бумажный документооборот
не работает обычно не более 30мин, суммарно в квартал 2-4 часа не работает.
Перспективный чат детектед! Сим повелеваю - внести запись в реестр самых обсуждаемых за последние 4 часа.
А как же "Цифровое здравоохранение"? Можно было бы Ваши предложения, накопившиеся за 4 года туда продвинуть. Кстати, они у Вас есть?
Чисто декларативная вещь.
Есть и полно... Только вот проблема: кого на правительственном уровне интересует мнение простого начальника оргметодотдела ведомственной медсанчасти? Так же как и мнение простого врача... Им академиков подавай и чиновников высокого ранга. Которые, кстати, очень приблизительно представляют, что и как происходит в реальности...
У них задачи такой нет - реализовывать разрозненные инициативы снизу. Кто-то должен проинтегрировать. Но ни целей, ни компетенций, ни мотивов на это нет. Вы, например, готовы выдать свой сырец "в части касающейся" и только.
Что касается чиновничьих деклараций, лицемерить не буду, сам не очень к этому отношусь. Тем не менее согласовательные структуры создаются. Конечно, это не интеграция, а кое-что другое, но все же.
16 февраля 2018 года, "В России создан консорциум «Цифровое здравоохранение»"
В том-то и беда. Информатизация - это нынче тренд. И чиновники относятся к нему как к тренду: побыстрее слепить что-то, неважно насколько работоспособное, и отрапортовать, что мероприятие успешно проведено. У нас изначально пошли не тем путем: задали сроки, к которым нужно перейти на цифру. Причем сроки - заведомо нереальные для того, чтобы сделать продукт, удовлетворяющий основную массу пользователей. И задачи, которые при этом поставлены, мало соотносятся с реальной деятельностью - в основном - это контроль, а не получение и выдача врачами необходимой для работы информации в удобной форме.
По уму надо было пару-тройку лет потратить на выяснение того, что нужно низовому звену для удобной и продуктивной работы, проведя опросы и исследования, сформулировать общую концепцию и только после этого запускать процесс информатизации в рамках этой концепции. То же, что сейчас выдают за концепцию - набор общих мест, весьма мало соотносящийся с реальной работой врачей. И пример этому как раз у вас под крестиком...
согласен, согласен. как раз то, что все "не по уму", а по срокам в стиле "надо было вчера" и печалит. Но, справедливости ради, нет сегодня соответствующих интеллектуальных структур, на которые чиновники могли бы спокойно опереться.
По-хорошему, начинать надо даже не со сбора низовых хотелок, а как раз с создания структур (например, типа генерального конструктора национальной системы здравоохранения с подчиненными ему главными конструкторами конкретных комплексов), способных системно увязать и потребности врачей-практиков и пациентов, и экономику процесса, и технологические потенциалы, и частную инициативу, и многое другое. Причем не давать этой структуре сразу задание: Разработать систему, ать-два! А как раз дать время на сбор данных, на предпроектные проработки, в т.ч. концептуальные, на разработку альтернативных ТЭО, на профессиональную и публичную дискуссию.
Как ни крути, нужна опережающая интеллектуализация. Для того, чтобы цифровизация заработала на благо общества, а не на интересы цифровизаторов.
ну, по порядку.
1. Автоматизация больнички ВСЕГДА индивидуальная информационная система. Всегда. Это закон.
Поэтому
продукты как таковые вообще нет смысла покупать. в принципе. И поэтому
2. Нужно брать не продукт, а человека (или двух) и технологию. Приходите на 2-3 курс вуза и говорите, что возьмете нерда(ов) на 2 года построить систему. За которую будете что-то там платить.
3. Выбор технологии.
верно, только с точностью до наоборот. Построение ИС на базе 1С занимает гораздо больше времени, чем то же самое на Oracle Apex. Я не с дивана говорю, а сам лично информатизировал на Апексе офтальмологическую клинику (внимание!) за два месяца.
Берётся бесплатный Оракл 11с, у него есть ограничения, но для больнички его с головой, инсталлируется на нём пятый апекс (тоже бесплатный) и вперёд. Вы ограничены только вашими запросами. Мест 20-30 даже не напрягаясь, а если больше, то в 2018 выйдет бесплатный оракл 18с - так это вообще зверь (как обещают). Ещё раз повторяю, я не с дивана говорю, я с этим всем работал лично.
Писать скрипты 1С - это пожизненная каторга для программиста. Их закончить никогда нельзя. Но конечно есть любители и этого. Вам решать.
3. По железу. Поскольку Апекс генерит html - это означает, что работать с системой - всё равно как посещать самый простейший сайт. Клиенту не нужно супер железо, не нужны операционные системы - хочешь линукс, хочешь андроид, хочешь винда, айфон - всё равно. Любой компьютер совместим. Совместимость полная и клиент самый лёгкий что может быть. Windows ХР на древнем компе - не проблема, ноутбук урожая 2003 года - на ура. Без разницы.
То есть экономия на модернизации.
4. Безопасность. Оракл - это оракл. Там по умолчанию встроены оба уровня - идентификация и авторизация.
Группы, доступ, почта - всё на уровне платного Оракла.
изменилось всё :) но не все об этом знают :)
Если будет интересно, могу про Апекс написать статью.
Довожу до вашего сведения, что СУБД MySQL также является собственностью Оракла. Если следовать вашей "логике" все провайдеры в РФ завтра упадут. Я скромно утверждаю, что этого не будет.
Оракл может выстрелить себе в ногу и не продать лицензию на платную базу. Но на бесплатную 11С лицензия не нужна.
Не пойдет. Это для частной клиники/кооператива. Любое ЛПУ территориального уровня мест 60-80 по минимуму, в среднем - больше сотни.
Вообще-то, «1С» с уровня 8.2 тоже может генерить хтмл, т.е. можно работать в режиме WWW-сервера, через браузер.
Странно. У нас каждый блок после запуска и тестирования в течение 3-х-6-ти месяцев, за которые вылезают все блохи, больше не менялся. Возможно проблема в организации системы?
Напишите, интересно. Особливо в плане закладок...
А как у этого всего с русификацией?
база стандартно
сам апекс в 10 языках без русского, кнопки переводить самостоятельно.
Вы с какого года пишете? CP1251 ISO8859 -- это же старые восьмибитные кодировки, которые лет 10 назад, если не больше, перестали использоваться.
ISO 8859-5
вполне себе юникоднаврал, действительно байт, но работает
Учитывайте еще, система МИС работает с ПД и в соответствии с законом все АРМ защищены криптосредствами. И цель системы видеть ,что происходит вообще. Например какое среднее время приема пациента врачом. Ну как тут не заволноваться. А деньги идут не в ГУЗы , а сразу поставка техники. А это у ТС лютую грусть вызывает.
Чушь какая. Здесь как раз очень строгие регламенты. И их стараются нен нарушать, ибо можно присесть если выяснится, что пациент умер в результате нарушения.
Отчасти соглашусь - коробочные продукты здесь не катят - они редко достаточно универсальны и удобны. Часто без разработчика/консультанта не осилить.
В любом деле рулит опыт. У студентов его НОЛЬ. Если вы наймете несколько такжиков и поставите им задачу построить дом - результат вас расстроит. А ведь они толковые ребята - все могут. Вот только без архитектора, прораба и бригадира это все ниочем.
Выбор технологии.
Апекс - это просто технология рисования интерфейса к базе. Их много таких. Она таки да - позволяет не парится с интерфейсом, но никак не гарантирует что будет разработана нормальная система. Студенты ее быстро нарисуют под хотелки пользователей. но в результате будет шняга.
Остальное не буду комментировать, я предпочитаю MS SQl. А учитывая российские тенденции - перейду на одну из опенсорсных СУБД.
взять третьекурсника толкового и пока напишет диплом напишет и базу. пусть со второго раза. it's ok. зато профессионал потратит почти столько же времени за совсем другие деньги поскольку студент энергичен и заинтересован, ему интересно. а профи начнёт диаграммы крутить, составлять планы, да ещё неспешно, клиент никуда не денется.
найти быстрого и качественного профи большая редкость. всё равно много времени займёт вникание в предмет, у студента это намного дешевле.
ну так любая информационная система - это и есть интерфейс доступа к базе. просто тут люди умудрились втиснуть достаточно сильный функционал в визуальную среду разработки, так что скорость разработки средней руки приложения в несколько раз выше чем того же мс ентити ;)
сидят сейчас рядом на энтити пишут базу, решают как будут генерить документы, третью сторону решили привлечь, а в апексе это встроено давно.
слон популярен зело. там много вкусного.
а функционал, который вы информатизировали, в нескольких предложениях опишите, пожалуйста
клиенты (карточка, CRUD, отчёты), врачи (CRUD), клиники , непересекающиеся рандеву (календарь, срезы по врачам, клиникам, тоже CRUD), оплата, предварительный осмотр, тесты, операции (это глазная клиника), архив сканов документов.
Очевидно, что должна быть единая государственная информационная медицинская система и веб-приложение для доступа к ней. Очень странно почему до сих пор не наведен порядок в этом вопросе. Опять-таки с записью на прием к врачу бардак, нет общей системы..
В недрах частной медицины ничего не назревает? Ставлю на крупную частную сеть клиник. Докрутят какую-нибудь существующую систему учёта под медицинские нужды.
А как за бугром в этом плане? Может есть что спереть?
Проблема в том, что у частной клиники и государственного ЛПУ - совершенно разные задачи. Я копал системы учета сделанные для частных клиник, в том числе и собственные их разработки. Там основная цель - налаживание и контроль бизнес-процессов, для того, чтобы раскрутить пациента по полной программе. Учетные задачи ставятся постольку-поскольку они соответствуют этим самым бизнес-процессам, а чисто медицинских задач не ставится от слова «совсем»...
А ставят ли в ФОМС задачу обеспечения здоровья людей?
Вот они и автоматизируют учет финансирования мелицинского обслуживания
Уже почти 25 лет наблюдаю со стороны процесс автоматизации в банкирском деле на примере Сбербанка. Как я понимаю, руководство захотело иметь нормальный "операционный день банка", чтобы вечером подбить остатки по всем филиалам и отделениям, а ночью крутить эти деньги на биржах, выдавая часовые кредиты торговцам и брокерам. Дело более-менее приобрело осмысленность, когда, спустя приблизительно 10 лет после начала телодвижений, в Московском городском банке Сбербанка смогли написать ТЗ на разработку ПО ОДБ с проработкой каждой операции до уровня граф-схемы алгоритма и точных формул вычислений при всех возможных исходных данных, всех возможных условиях и ограничениях. Это ТЗ писали не программисты, а ведущие специалисты операционных отделов и прикладные математики, выполнявшие роль постановщиков задачи для программистов. Заняла эта работа по трудоёмкости 400 человеко-лет. Поскольку районная поликлиника обслуживает приблизительно столько же населения, сколько филиал (с доп. офисами), сложность задачи - сопоставима. Сопоставима и трудоёмкость написания ТЗ. Ну, а уже по хорошему ТЗ любая ИТ фирмочка, численностью от 700 до 2500 сотрудников напишет вам ПО и будет всю жизнь его долизывать под любые капризы заказчика и законодателя-нормотворца. Это же золотое дно. А чтобы код был открытым - записать в ТЗ как обязательные условия минимум две вещи: 1) предъявить ПО в соответствии с ЕСПД и сдать его в установленном порядке в ЕФАП; 2) получить в установленном порядке сертификат на отсутствие в ПО недекларированных возможностей. Акт приёмки ЕФАП и сертификат на отсутствие закладок считать неотъемлемым приложением к Акту выполненных работ.
Да, это чуть ли не единственный вариант рабочий когда заказчик сам может написать корректное ТЗ, Причём не с точки зрения разработчика, а именно с точки зрения учета требований всех заинтересованных в системе (требования разных заинтересованных лиц очень часто противоречат друг другу). Это практически нереально сделать не обладая специальными навыками и не имея экспертизы в предметной области.
НО. Ваше предложение не решение. Нет ни одного проекта разработки где бы Изначальное ТЗ остаётся актуальным во время проекта. Материал слишком гибкий. Очень много требований меняются на всём протяжении проекта. И после его окончания тоже. И ваше предложение предоставить код по ЕСПД ( распечатанный) устареет через парунедель после запуска системы. Потому что появятся новые требования. Они всегда появляются.
ТЗ - живой организм, живущий своей жизнью. Для этого предусмотрены дополнения и изменения в ТЗ, и существует установленный порядок их проведения. Существует также и порядок сопровождения продукта в условиях эксплуатации, уже после окончания разработки. Как говорится: "Всё украдено до нас" ©.
Как может устареть учтённый экземпляр - ума не приложу.
Вы можете объяснить, - как это может случиться, если в нём проводятся все Извещения?
А, вы о реальном и полном следовании ЕСПД.
Так еще лучше - за чей счет банкет?
Кто будет оплачивать реальное методическое обеспечение этого процесса на ВСЕМ протяжении жизненного цикла системы, до момента ее вывода из эксплуатации и архивирования?
Причем заметьте - автору повезло - он может поставить задачу, судя по результатам. Кто в больнице озаботится корректным ведением документации и СМОЖЕТ проконтролировать корректность этой документации и соответствие ее с системой?
В этом и проблема - времена когда ТЗ писали профильные НИИ для использования в своих недрах прошли безвозвратно.
В этом и различие между ВПК и остальными отраслями. У них ещё сохранилась технология взаимодействия подразделений внутри себя.
Ой-ей. Я такое видел на предприятиях ВПК, что волосы дыбом на всех местах встают. какой там 34 и 19 гост, какое там хотя-бы управление требованиями, какое там управление проектами. Деградация тотальная. От предприятия зависит.
Ну и проблема ВПК в затратах＋ нет мотива оптимизацией заниматься. если можешь обосновать свою себестоимость делай что хочешь, или не делай. Другое дело, что часто слышу, что сейчас приемка стала часто иметь претенщии не только к уровню себестоимости, но и к структуре. вот это круто, в умелых руках и если без перегибов.
В атомке судя по всему с обсуждвемыми нами делами все достаточно хорошо - сохранили преимущество и советского подхода и современные подходы тоже используют во благо. но сужу только по публичным результатам информации не имею. Хотя опять же - там все в рамках жесткой вертикали, по сути одной компании.
Осетра можно смело урезать на порядок, а потом еще раза в два -три. Чай 21 век на дворе. это про количество сотрудников.
Вы имеете в виду сертификат ФСТЕК ?
Вы представляете сколько это стоит?
Вы понимаете, что софт постоянно дописывается и как это относится к сертификату ФСТЭК?
Много ли в РФ есть МИС с сертификатом ФСТЭК?
, ведь нанять программиста на "1С" проще и дешевле, чем на «Oracle» или «Delphi».
Проще - не значит лучше. И кто сейчас интерфейс на дельфях пишет?
Угу. В детской психиатрии автоматизации нет вообще. До сих пор возим бумажки. Москва, кстати. Вопрос, как это изменить.
в психиатрии жесткая нормативная база, не везде можно использовать ПК. какие-то диагнозы только на бумаге ведутся.
Неа. Внутри больницы уж лет 15 сеть была с самописной базой и программами учета. Внутри ПНД тоже сетка. А детские психиатры возят бумажечки.
«На бумаге» - совершенно не означает «только в рукописном виде», как это трактуют подавляющее большинство чиновников. Вполне можно распечатать набранный на компе текст. А для решения юридических коллизий вполне достаточно подписи с рукописной расшифровкой фамилии.
я имел в виду, что нельзя вести приём в общей БД учетной системы, в виду имеющегося доступа у персонала не относящегося к лечебному процессу.
Не вижу никакой проблемы. Все решается разделением доступа и простейшими административными мерами. Ничуть не сложнее, чем хранение чисто бумажной информации.
Вис ис э роад ту хэл...
Полная чушь и ахинея. Погуглите что такое Электронная регистратура, Медицинская Информационная Система ЕСИА и как все интегрировано с Госуслугами. Во многих городах работает МИС от Барс.
https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B4%D0%B8%D1%86%D0%B8%D0%BD...
Извините, это у вас чушь и ахинея. Мне гуглить ничего не надо, я работаю в этой области уже далеко не один год и широко и плотно контактирую с людьми, которые всеми этими вторпродуктами пользуются. Может быть Минздрав и чиновников в правительстве все это и устраивает, но тех кто работает на местах, непосредственно с пациентами, - нет.
Это везде так, не только в медицине.
Повторюсь -вы грустны и делаете вброс в связи со снижением возможностей увеличения вашей кормовой базы И от ТФОМСа и от Пациетов.
У вас с головой все в порядке? Какое снижение кормовой базы может быть у начальника оргметодотдела в ведомственной медсанчасти? Меня автоматизация интересует исключительно с целью получать актуальные оперативные и учетные данные, причем для себя я эту проблему уже решил. А вот за других коллег - действительно грустно. И советую вам почитать «Правила ведения дискуссии в данном блоге (техническое)», особенно примечание к первому пункту. Чтобы потом не было больно и обидно.
(На правах очевидца)
Года три-четыре назад наблюдал со стороны взаимодействие одного из некоммерческих фондов с Барсовцами... Выглядело это так:
Б: Вы нам опишите бизнес-процессы, приложите формы документов, укажите что, где, куда заполнять и все мы сделаем.
Ф: Вот наше положение и два регламента, в них указан порядок всех наших действий и формы документов. Это будет черновик. Как оформите в бизнес-процессы, мы вам подробно по каждому пункту расскажем.
Б: Мы ничего не поняли, нарисуйте бизнес-процессы...
Ф: у нас нет специалистов, что смогут нормально это сделать... приезжайте, мы соберем начальников отделов и они вам все подробно расскажут.
Длилась эта бодяга где-то квартал.. потом что-то вроде ТЗ наваялось и пошло твориться... Приемка прошла в три попытки... ибо при первой попытке нашли ошибки в арифметике... в итоге после долгих мытарств система так и не была запущена.
Да, особо доставлял еще один момент. В этой системе должны были работать с ПД граждан... ФИО + прописка + еще немного... и для отработки системы Барсовцам дали тестовый массив данных... тысяч на 10... при этом покорябав их (перемешали фио и адреса между записями), чтобы не сесть за разглашение... но Барсовцы зачем-то постоянно выпрашивали полный рабочий массив данных... и доказывали, что представленный массив их не устраивает и именно из-за него система нормально не работает... при этом объяснить почему на малой выборке система нормально не работает, а на полном рабочем объеме вдруг заработает нормально так и не смогли.
Может с тех пор что-то и изменилось в их фирме.. но проверять как-то не хочется.
"Ни в одной из исследованных программ автоматизации" умиляет.
Годный срач. Ахтунг - пахнет трольчатиной! Автор, нет ли в обсуждении упырей? Сим повелеваю - внести запись в реестр самых обсуждаемых за день.
Уверяю вас, все то же самое в любой другой отрасли. Часто когда организация может позволить себе потратить миллион другой долларов не "внедрение" ИТ-системы, потом всем приходится подстраиваться и делать вид что все работает. Причин у этого много, но вся ИТ-отрасль в России "карго культ". Вы нашли решение, но оно имеет ряд недостатков:
1. Судя по всему у вас неплохой ИТ-бэкграунд, вы что-то делали самостоятельно в части разработки приложений и на уровне талантливого самоучки без инженерного образования имеете очень хорошее представление об этом процессе. Предположу что именно это повлияло на то, что в итоге хоть что то получилось.
2. Так же возможно вам повезло с разработчиком которого вы наняли.
3. И теперь самое важное. Я очень сомневаюсь что ваша система будет способной жить и меняться (а меняться она будет постоянно) БЕЗ автора. То есть без этого самого разработчика. Проблема в том, что инженерия Требований и инженерия ПО не в шутку так называются.
А крупные и "профессиональные" Системы заточены под того стейкхолдера который платит деньги :(
к сожалению непосредственно пользователям таких систем как правило кроме новых обязанностей почти ничего не перепадает.
Системная инженерия вроде бы начала нащупывать верное направление, но это все сейчас очень сильно в зачатке и так же имеет массу ограничений.
Не могу спорить. Я занимаюсь подобным с начала 90-х, с тех пор как в личном пользовании появился компьютер. С тех пор всегда сам для себя делаю учетные системы. Первые делал еще на том Paradox-е, который был под ДОС
. Всегда интересовался информационными системами и копался во всех новинках. Так что кое-какой опыт имеется.
Не-а. Обычный «1С»-кодер, который максимум на что способен - это сделать то, что ему в деталях разъяснили. В принципе, в роли того, что вы называете «разработчиком», выступал я сам. Сам определял, какая информация и как должна вводится и выводиться, в каком виде сохраняться ну и так далее. Правда делал я это только после того, как вопрос был плотно «перетоптан» с соответствующими врачами и мне самому становилось все ясно. Именно поэтому врачам и удобно ей пользоваться. Кроме того, я учитывал все те «мелочи», которые могут возникнуть в ходе статистического учета, поскольку решать их приходилось все равно мне же как начальнику ОМО. Плюс всегда расспрашивал о деталях соответствующих специалистов.
Жить она будет уже и без меня, все достаточно хорошо построено и оттестировано. Коренных изменений не предвидится, поскольку построена система по тем принципам медицинского статистического учета, которые приняты на настоящий момент и вряд ли будут меняться на протяжении еще десятка-другого лет. Мелочь типа изменения отчетных форм можно будет сделать и без меня, поскольку я подготовил пару человек, которые смогут правильно поставить задачу кодеру.
Вы нашли хорошее решение, я всем всегда говорю, лучше разрабатывать самим, но нужно уметь именно управлять разработкой.
И все же буду настаивать на том, что данное решение очень неустойчиво к изменениям. вы утверждаете, что меняться там нечему - допустим. но поменяться могут требования вместе с реальными людьми, поменяться требования к окружению (например необходимость интеграции с какой либо системой или обеспечение работы на другой платформе с новыми требованиями по безопасности, или необходимость перехода на другую платформы той же 1с из-за бещопасности например или требования законодательтсва, например 152фз - вы кстати уверены что вы его требования соблюдаете?）.
При этом представьте, что вы ушли на повышение, а код 1с программистом сляпан так, что другой человек не сможет разобраться - это бывает сплошь и рядом и сам он уже давно архитектор решений в другом городе.
Это слабое место всегда остается - зависимость от авторов, конкретных личностей. Иногда эти личности начинают себя вести не совсем коррнктно, понимая свою такую значимость.
При этом, найм компании за много денег на дорогой платформы, вроде должно решить проблему, но если неправильно управлять разработкой зависимость появляется дорогая, от внешней компании и иногда даже от персон этой внешней компании, что в разы хуже, чем ваш вариант.
Страницы