Трудно сказать. Это полное перепроектирование всей конструкции с нуля
Думаю как у стандартных промышленных роботов — 1m+
Можно сэкономить на том, что просто скопируешь что-то готовое, но проиграть на отлове косяков, которые крупные производители поймали и исправили уже лет 20 назад.
Есть концевые датчики — они не позволяют выйти за крайние положения по каждой из осей + их можно использовать для определения собственного положения в начале/конце цикла. Но во всех остальных случаях робот не имеет обратной связи и опирается только на число сделанных шагов.
Сначала пытались запуститься на своих деньгах.
Потом найти инвестора (не получилось — слишком ранняя стадия)
Потом начался бум краудфаундинга, но я тогда уже понял, что сроки плывут непредсказуемым образом. Это было не рациональное, а этическое решение — я решил, что не хочу брать деньги за результат, который не могу гарантировать хотя бы с 50%-ной вероятностью.
Да, Гришин вкладывается в проекты, я общался на ранних этапах проекта с представителями его фонда. Но тогда они неофициально сказали, что проект не совсем в их фокусе, но пожелали удачи и дали несколько хороших рекомендаций.
На самом деле нет, там плавный разгон и, возможно, торможение, просто его не очень хорошо видно, т.к. скорость не максимальная и участок с ускорением быстро проходит. Мы могли запустить его быстрее (примерно в 2-3 раза), но по соображениям безопасности (вокруг куча детей) не стали этого делать. Ну и еще мы боялись возможного перегрева, износа редукторов, вибраций, внутреннего отрыва проводов и кучи других вещей, поэтому решили тогда запускать в медленном варианте))
При мгновенном разгоне действительно есть пропуск шагов или даже невозможность сдвинуться с места.
Энкодеры — возможно уже да. Но когда мы начинали разработку (года четыре назад), оказывалось, что отслеживание движений по каждой оси с точностью, хотя бы, в 5 градусов, удваивает цену конструкции и увеличивает количество проводов сверх всякой меры. и мы решили их не использовать
Моя любимая проблема: мы соединили вал редуктора и двигателя муфтой. Муфта была не очень хорошей и для надежности, пока не придет новая партия, мы посадали ее на клей. Но после половины дня работы, из-за нагрева, клей расплавился и превратился в отличную смазку.
А вообще куча проблем, которые вроде-бы очевидны, но о которых не думаешь в начале. Скрутка проводов — не надежна. Пришлось везде, где есть какое-то движение, ставить разъемы. Программа управления не всегда корректно взаимодействует с драйверами шагового двигателя — пришлось переходить с MACH3 на программу от purelogic (кстати, похоже, она удобней). Двигатели недостаточно мощные и могут перегреваться — пришлось их увеличивать. Компрессор пневмосистемы может перегреваться. Электроника может перегреваться. Не все муфты одинаково надежны. Провода могут перетираться и коротить друг друга, если их провести не правильно. При сильных внешних вибрациях редукторы начинают на малые доли секунды заедать -> пропуск шагов. И куча других вещей, которые последовательно возникают перед тобой. После того, как решена одна проблема, обычно еще две-три минимум в очереди.
После первого запуска робот проработал полчаса, потом еще полчаса, потом еще 10 минут. Мы учли ошибки и за пару месяцев их исправили. В следующей серии испытаний, это были промежутки в несколько часов. После очередной порции исправлений — от половины дня до нескольких суток. В результате каждой итерации робот, очевидно, становится лучше. Но, столь же очевидно, впереди все еще долгий путь, прежде чем, мы дойдем до надежности, вида «можно на полгода оставить без присмотра и ничего не случится».
Спасибо за рекомендации, я обдумаю их.
В конце мы действительно разделили конструкторскую часть и продажи (точнее они самопроизвольно разделились) — и это сдвинуло дело с мертвой точки.
Да, я планировал использовать робота для своих целей. Не сразу, после отладки косяков на других заказчиках, но все же. Похоже, что да, если бы план развития подразумевал, использование робота для своих нужд с самого первого прототипа — развитие проекта пошло бы по другому, более оптимистичному пути.
Примерно то же время, которое я занимаюсь роботом, я работаю по найму в страховой компании (автоматизация, отчетность, оптимизация процессов) и я понимаю, что меня в общем-то все устраивает.
Сейчас хотелось бы попытаться вырасти внутри крупной компании по должности/зарплате.
Это даст новые возможности.
Во-первых я смогу с новыми ресурсами запустить что-то свое.
Во-вторых, как я уже понял, крупным компаниям нужны крутые инновационные проекты, они их активно ищут. Люди, которые могут их запускать, в дефиците везде. Если ты сделал что-то, что экономит или приносит деньги и у этого чего-то хороший потенциал для развития — ты можешь сделать на его основе внутренний стартап. У тебя будут несопоставимо большие ресурсы, более высокая зарплата и гарантированный рынок сбыта. Да, ты не будешь владельцем итогового решения и не получишь все возможные плюсы от него, но косвенные бонусы предоставляемые работодателем с лихвой это все перекроют.
Так что ближайший план — сделать что-то крутое внутри крупной компании (мне сейчас нравится машинное обучение и сегментирование клиентов в оффлайне). Это реально и, похоже, это проще. Просто нужны другие навыки.
Тут две ветки ответа — первая — кому интересно в принципе, вторая — какие реально продажи.
Начну со второй (грустной) части. Продаж именно робота нет. Не из-за того, что спроса нет, а из-за того, что я не готов был делать продажи конструкции, которая была объективно не готова к замене труда человека на достаточно качественном уровне. Сначала нам не хватало надежности, потом — не довели до конца работу с кодом (робот не учитывал в своей работе показания концевых датчиков по каждой из осей => на каждом цикле накапливалась ошибка => нужен был человек рядом для контроля производимых действий). Вроде бы сейчас все проблемы решили и на последнем выезде на выставку за экспонирование нам платят деньги, но подробностей и конкретной суммы я не знаю, произошло уже после моего ухода.
Продажи есть, но не там, где мы ожидали. В процессе разработки робота мы сделали неплохие червячные редукторы которые идеально под наши цели подходят. И внезапно оказалось, что они-то как раз нужны людям. У них отличные характеристики и относительно низкая цена. На данный момент мы делаем и продаем их. Это плюс — параллельно обкатываются процессы производства редукторов для робота и снижается их себестоимость. и еще благодаря им мы начали выходить в ноль (ну или не такой большой минус, как раньше). Но у них очень долгий цикл продаж — несколько месяцев — поэтому есть надежда, что в будущем ситуация будет улучшаться.
Теперь о первой части — кто в принципе хотел купить робота. Было три больших группы потенциальных заказчиков.
Первые — конечные пользователи со своим небольшим бизнесом. С помощью робота они хотели мыть машины, сваривать металлические двери, складывать коробки (таких, внезапно, было трое из разных концов страны), разливать напитки и куча всего еще.
Второе — посредники-консалтеры, которые специализируются на робототехнике и хотели бы предлагать своим клиентам нашего робота как дешевую альтернативу имеющимся на рынке промышленным роботам в тех областях, где высокие характеристики не нужны. Меня удивило, что конечные пользователи продукции, которым хотели поставлять эти решения, в половине случаев были как-то связаны с оборонкой (от тестирования детонаторов до сборки самолетов).
Третье — самая большая группа — люди, которым робот нужен был просто как яркий объект для привлечения внимания. «Давайте мы поставим его к себе в магазин, люди будут заходить посмотреть и что-то купят заодно». Их не волновало — что именно робот будет делать, главное чтобы он двигался и привлекал внимание. Для них важна была только эта характеристика и, в общем-то, никакой разницы между роботом, абстрактной скульптурой или промоутером для них не было. В итоге, мы решили, на время, пока обкатываем конструкцию, продавать/сдавать робота именно таким заказчикам, при условии, что они территориально будут недалеко от нас. У меня нет последней информации по проекту, но, полагаю, что с выставкой (упомянутой в статье) сейчас все идет хорошо. Если это так — в ближайшее время разместим еще пару роботов где-нибудь еще по Москве.
Если хотите обсудить тему подробней — можете в личку написать. Мне будет интересно посмотреть на проблемы за пределами моей текущей области деятельности (страхование) и понять — применимы ли там мои рекомендации на практике)
Прием который я видел на практике:
— неквалифицированные сотрудники контролируют что пришла вся необходимая документация (должны прийти 5 документов — до тех пор, пока все они не пришли, готовый пакет документов не передается дальше в работу). Т.е. высококвалифицированные специалисты не тратят время на переписку с клиентом. Вся необходимая для работы информация у них в момент начала работы уже на руках.
— сюда можно добавить разметку внутри документа — на какой странице какая информация. Обычно полезная инфа хранится в 2-3 основных разделах, остальные практически не влияют на принятие решения. Нужно чтобы эти разделы могли быстро найти.
— Аналогично — если есть формальные признаки для отсеивания заведомо ненужно для анализа информации (например, «документ не содержит чертежей») — их нужно использовать для уменьшения количества поступающей к специалисту информации.
Дальше можно пытаться алгоритмизировать работу самого человека оценивающего проект, но это очень специфичная для каждой области вещь.
Если пытаться сводить эти возможности к единому знаменателю:
1. Составьте алгоритм выполнения задачи «в общем случае»
2. те части, которые содержат однозначную последовательность действий — отдайте неквалифицированным сотрудникам или реализуйте в виде программы.
3. Те части, которые «требуют творческого подхода» отдайте квалифицированным сотрудникам или попытайтесь опять выполнить пункт 1 — иногда «творческий подход» — это набор из 3-5 правил.
Ответ может быть не релевантен поскольку в этих областях не работал)
Но обычно я начинаю с создания однозначных последовательностей действий на самом нижнем уровне, которые объединял в более общие на верхнем. Например, в случае с ремонтом стен, могу предложит следующий вариант — человек приезжая на объект заполняет подробную анкету однозначно описывающую необходимые действия (материал стены, площадь, несущая/не несущая, дефекты поверхности (выбор из закрытого списка), желаемый тип доработки, требования по шуму, требования по допустимому времени работы, ...). Т.е. отвечает на закрытый перечень вопросов. Затем на основе этих ответов однозначным образом рассчитывается стоимость услуги и время выполнения от которой не отступают в дальнейшем. Затем запускается шаблонная последовательность действий по вызову бригады и т.д.
В данном случае элементарными операциями является сбор исчерпывающей информации (1) и расчет стоимости на ее основе (2). Человек собирающий данные (1) может не иметь квалификации для оценки стоимости работ, но это от него и не требуется. Его единственная функция на данном этапе — собрать корректную и исчерпывающую информацию. Затем он передает собранные данные (привозит в офис заполненные от руки бумажные бланки или отправляет через специальное приложение на планшете — не важно), на основе которых происходит оценка работ (2). Если данных не достаточно для однозначной оценки — либо не все данные собраны либо используемая модель оценки некорректна. Их можно будет улучшит в будущем в следующих итерациях взаимодействия с другими клиентами, когда появится статистика по тому насколько выставляемая клиенту стоимость работ отличается от реальной и почему так получилось.
Да, мой косяк. Изменил формулировку с «что опоздает хоть кто-нибудь из них» на «что никто не опоздает».
Поскольку вероятность опоздания примерно равна вероятности успеть в срок, дальнейший текст править не стал)
Мне кажется, что это стандартная мантра при любом программировании: «вешай столько проверок на корректность данных, сколько можешь придумать». Каждая проверка, которую ты придумал, рано или поздно сработает — и спасет кучу твоего времени.
Нет, никаких особенно это не оформляли. Отдел, в котором я работал, занимался актуарными расчетами + аналитикой (как внешней так и внутренней) + автоматизацией. Из-за этого весь процесс разработки и одобрения был предельно коротким:
— я пришел в сб чтобы поиграть с данными, попутно написал первую версию функции и проверил ее качество
— в пн скинул начальнику результаты и спросил можно ли мне проапдейтить исторические данные + установить запрет на занесение новых людей с неправильным полом на уровне триггера. за 15 минут получил одобрение.
— в среду, когда появилось свободное время, сделал задуманное + оповестил тех сотрудников, которые должны были с этой проверкой столкнуться.
Поскольку хренение [застрахованных-физлиц для медицинских договоров] и [всех прочих контрагентов] было в разных таблицах (по историческим причинам), то все прошло довольно безболезненно.
Первая ошибка определения пола пришла примерно через месяц после того, как я установил эту проверку.
Это не очень клиентоориентированно)
Можно, отказывать в выплате, но мне кажется, что определение пола и корректных тарифов — наша проблема, а не клиентов. Ну например, у клиентов эта информация может просто не хранится в их системе кадрового учета.
О суброгациях: возможно они присутствовали в неявном виде до того как я начал реализацию проекта (в момент согласования с клиентом счета за очередную рассрочку — ибо, как ни странно, этот процесс был очень далек от стандартизации).
Да, большая часть информации попадает в базу из excel — файлов присылаемых клиентами. Они на своей стороне генерят эти файлы из своих систем, где они ведут кадровый учет. По вполне понятным причинам мы не можем проверять биологический пол при принятии на страхование (особенно когда коллектив 10+ тысяч человек, но даже для одного человека это было бы, гхм, двусмысленной проверкой).
Ни в одном месте где я работал, не было разделения на биологический и декларируемый пол. Вероятная причина — различие между ними встречается столь редко, что потенциальная недополученная прибыль теряется на фоне других, гораздо более мощных факторов. Если наши сотрудники осуществляющие контроль счетов от мед учереждений увидят, что пол не соответсвует декларации — они просто изменят его или повесят соответсвующий повышающий коэф на человека с уместным случаю комментарием (т.е. при повторном принятии на страхование застраховаться по стандартным тарифам он не сможет).
Ну, стоит это скептически воспринимать))
Я просто не придумал никакого более надежного способа проверки, чем ручной. Но в реальности, этот способ может быть ужасен: агент хочет продать страховку китайцу (физлицу) — система говорит что пол не верный — продавец меняет пол на тот, который система требует (не отказываться же от сделки?) и никому ничего не говорит. Да будут какие-то отличия в печатном бланке, но авось клиент не заметит.
Я смотрел изредка логи — на каких именах срабатывает проверка. В подавляющем большинстве случаев я был согласен с решением функции, но для части срабатываний у меня не было уверенности. Так что, возможно, ошибок было не 6, а в несколько раз больше. Что, впрочем, тоже довольно неплохо.
Думаю как у стандартных промышленных роботов — 1m+
Можно сэкономить на том, что просто скопируешь что-то готовое, но проиграть на отлове косяков, которые крупные производители поймали и исправили уже лет 20 назад.
Потом найти инвестора (не получилось — слишком ранняя стадия)
Потом начался бум краудфаундинга, но я тогда уже понял, что сроки плывут непредсказуемым образом. Это было не рациональное, а этическое решение — я решил, что не хочу брать деньги за результат, который не могу гарантировать хотя бы с 50%-ной вероятностью.
Да, Гришин вкладывается в проекты, я общался на ранних этапах проекта с представителями его фонда. Но тогда они неофициально сказали, что проект не совсем в их фокусе, но пожелали удачи и дали несколько хороших рекомендаций.
При мгновенном разгоне действительно есть пропуск шагов или даже невозможность сдвинуться с места.
Энкодеры — возможно уже да. Но когда мы начинали разработку (года четыре назад), оказывалось, что отслеживание движений по каждой оси с точностью, хотя бы, в 5 градусов, удваивает цену конструкции и увеличивает количество проводов сверх всякой меры. и мы решили их не использовать
А вообще куча проблем, которые вроде-бы очевидны, но о которых не думаешь в начале. Скрутка проводов — не надежна. Пришлось везде, где есть какое-то движение, ставить разъемы. Программа управления не всегда корректно взаимодействует с драйверами шагового двигателя — пришлось переходить с MACH3 на программу от purelogic (кстати, похоже, она удобней). Двигатели недостаточно мощные и могут перегреваться — пришлось их увеличивать. Компрессор пневмосистемы может перегреваться. Электроника может перегреваться. Не все муфты одинаково надежны. Провода могут перетираться и коротить друг друга, если их провести не правильно. При сильных внешних вибрациях редукторы начинают на малые доли секунды заедать -> пропуск шагов. И куча других вещей, которые последовательно возникают перед тобой. После того, как решена одна проблема, обычно еще две-три минимум в очереди.
После первого запуска робот проработал полчаса, потом еще полчаса, потом еще 10 минут. Мы учли ошибки и за пару месяцев их исправили. В следующей серии испытаний, это были промежутки в несколько часов. После очередной порции исправлений — от половины дня до нескольких суток. В результате каждой итерации робот, очевидно, становится лучше. Но, столь же очевидно, впереди все еще долгий путь, прежде чем, мы дойдем до надежности, вида «можно на полгода оставить без присмотра и ничего не случится».
В конце мы действительно разделили конструкторскую часть и продажи (точнее они самопроизвольно разделились) — и это сдвинуло дело с мертвой точки.
Да, я планировал использовать робота для своих целей. Не сразу, после отладки косяков на других заказчиках, но все же. Похоже, что да, если бы план развития подразумевал, использование робота для своих нужд с самого первого прототипа — развитие проекта пошло бы по другому, более оптимистичному пути.
Сейчас хотелось бы попытаться вырасти внутри крупной компании по должности/зарплате.
Это даст новые возможности.
Во-первых я смогу с новыми ресурсами запустить что-то свое.
Во-вторых, как я уже понял, крупным компаниям нужны крутые инновационные проекты, они их активно ищут. Люди, которые могут их запускать, в дефиците везде. Если ты сделал что-то, что экономит или приносит деньги и у этого чего-то хороший потенциал для развития — ты можешь сделать на его основе внутренний стартап. У тебя будут несопоставимо большие ресурсы, более высокая зарплата и гарантированный рынок сбыта. Да, ты не будешь владельцем итогового решения и не получишь все возможные плюсы от него, но косвенные бонусы предоставляемые работодателем с лихвой это все перекроют.
Так что ближайший план — сделать что-то крутое внутри крупной компании (мне сейчас нравится машинное обучение и сегментирование клиентов в оффлайне). Это реально и, похоже, это проще. Просто нужны другие навыки.
Начну со второй (грустной) части. Продаж именно робота нет. Не из-за того, что спроса нет, а из-за того, что я не готов был делать продажи конструкции, которая была объективно не готова к замене труда человека на достаточно качественном уровне. Сначала нам не хватало надежности, потом — не довели до конца работу с кодом (робот не учитывал в своей работе показания концевых датчиков по каждой из осей => на каждом цикле накапливалась ошибка => нужен был человек рядом для контроля производимых действий). Вроде бы сейчас все проблемы решили и на последнем выезде на выставку за экспонирование нам платят деньги, но подробностей и конкретной суммы я не знаю, произошло уже после моего ухода.
Продажи есть, но не там, где мы ожидали. В процессе разработки робота мы сделали неплохие червячные редукторы которые идеально под наши цели подходят. И внезапно оказалось, что они-то как раз нужны людям. У них отличные характеристики и относительно низкая цена. На данный момент мы делаем и продаем их. Это плюс — параллельно обкатываются процессы производства редукторов для робота и снижается их себестоимость. и еще благодаря им мы начали выходить в ноль (ну или не такой большой минус, как раньше). Но у них очень долгий цикл продаж — несколько месяцев — поэтому есть надежда, что в будущем ситуация будет улучшаться.
Теперь о первой части — кто в принципе хотел купить робота. Было три больших группы потенциальных заказчиков.
Первые — конечные пользователи со своим небольшим бизнесом. С помощью робота они хотели мыть машины, сваривать металлические двери, складывать коробки (таких, внезапно, было трое из разных концов страны), разливать напитки и куча всего еще.
Второе — посредники-консалтеры, которые специализируются на робототехнике и хотели бы предлагать своим клиентам нашего робота как дешевую альтернативу имеющимся на рынке промышленным роботам в тех областях, где высокие характеристики не нужны. Меня удивило, что конечные пользователи продукции, которым хотели поставлять эти решения, в половине случаев были как-то связаны с оборонкой (от тестирования детонаторов до сборки самолетов).
Третье — самая большая группа — люди, которым робот нужен был просто как яркий объект для привлечения внимания. «Давайте мы поставим его к себе в магазин, люди будут заходить посмотреть и что-то купят заодно». Их не волновало — что именно робот будет делать, главное чтобы он двигался и привлекал внимание. Для них важна была только эта характеристика и, в общем-то, никакой разницы между роботом, абстрактной скульптурой или промоутером для них не было. В итоге, мы решили, на время, пока обкатываем конструкцию, продавать/сдавать робота именно таким заказчикам, при условии, что они территориально будут недалеко от нас. У меня нет последней информации по проекту, но, полагаю, что с выставкой (упомянутой в статье) сейчас все идет хорошо. Если это так — в ближайшее время разместим еще пару роботов где-нибудь еще по Москве.
— неквалифицированные сотрудники контролируют что пришла вся необходимая документация (должны прийти 5 документов — до тех пор, пока все они не пришли, готовый пакет документов не передается дальше в работу). Т.е. высококвалифицированные специалисты не тратят время на переписку с клиентом. Вся необходимая для работы информация у них в момент начала работы уже на руках.
— сюда можно добавить разметку внутри документа — на какой странице какая информация. Обычно полезная инфа хранится в 2-3 основных разделах, остальные практически не влияют на принятие решения. Нужно чтобы эти разделы могли быстро найти.
— Аналогично — если есть формальные признаки для отсеивания заведомо ненужно для анализа информации (например, «документ не содержит чертежей») — их нужно использовать для уменьшения количества поступающей к специалисту информации.
Дальше можно пытаться алгоритмизировать работу самого человека оценивающего проект, но это очень специфичная для каждой области вещь.
Если пытаться сводить эти возможности к единому знаменателю:
1. Составьте алгоритм выполнения задачи «в общем случае»
2. те части, которые содержат однозначную последовательность действий — отдайте неквалифицированным сотрудникам или реализуйте в виде программы.
3. Те части, которые «требуют творческого подхода» отдайте квалифицированным сотрудникам или попытайтесь опять выполнить пункт 1 — иногда «творческий подход» — это набор из 3-5 правил.
Но обычно я начинаю с создания однозначных последовательностей действий на самом нижнем уровне, которые объединял в более общие на верхнем. Например, в случае с ремонтом стен, могу предложит следующий вариант — человек приезжая на объект заполняет подробную анкету однозначно описывающую необходимые действия (материал стены, площадь, несущая/не несущая, дефекты поверхности (выбор из закрытого списка), желаемый тип доработки, требования по шуму, требования по допустимому времени работы, ...). Т.е. отвечает на закрытый перечень вопросов. Затем на основе этих ответов однозначным образом рассчитывается стоимость услуги и время выполнения от которой не отступают в дальнейшем. Затем запускается шаблонная последовательность действий по вызову бригады и т.д.
В данном случае элементарными операциями является сбор исчерпывающей информации (1) и расчет стоимости на ее основе (2). Человек собирающий данные (1) может не иметь квалификации для оценки стоимости работ, но это от него и не требуется. Его единственная функция на данном этапе — собрать корректную и исчерпывающую информацию. Затем он передает собранные данные (привозит в офис заполненные от руки бумажные бланки или отправляет через специальное приложение на планшете — не важно), на основе которых происходит оценка работ (2). Если данных не достаточно для однозначной оценки — либо не все данные собраны либо используемая модель оценки некорректна. Их можно будет улучшит в будущем в следующих итерациях взаимодействия с другими клиентами, когда появится статистика по тому насколько выставляемая клиенту стоимость работ отличается от реальной и почему так получилось.
Поскольку вероятность опоздания примерно равна вероятности успеть в срок, дальнейший текст править не стал)
— я пришел в сб чтобы поиграть с данными, попутно написал первую версию функции и проверил ее качество
— в пн скинул начальнику результаты и спросил можно ли мне проапдейтить исторические данные + установить запрет на занесение новых людей с неправильным полом на уровне триггера. за 15 минут получил одобрение.
— в среду, когда появилось свободное время, сделал задуманное + оповестил тех сотрудников, которые должны были с этой проверкой столкнуться.
Поскольку хренение [застрахованных-физлиц для медицинских договоров] и [всех прочих контрагентов] было в разных таблицах (по историческим причинам), то все прошло довольно безболезненно.
Первая ошибка определения пола пришла примерно через месяц после того, как я установил эту проверку.
Можно, отказывать в выплате, но мне кажется, что определение пола и корректных тарифов — наша проблема, а не клиентов. Ну например, у клиентов эта информация может просто не хранится в их системе кадрового учета.
О суброгациях: возможно они присутствовали в неявном виде до того как я начал реализацию проекта (в момент согласования с клиентом счета за очередную рассрочку — ибо, как ни странно, этот процесс был очень далек от стандартизации).
Ни в одном месте где я работал, не было разделения на биологический и декларируемый пол. Вероятная причина — различие между ними встречается столь редко, что потенциальная недополученная прибыль теряется на фоне других, гораздо более мощных факторов. Если наши сотрудники осуществляющие контроль счетов от мед учереждений увидят, что пол не соответсвует декларации — они просто изменят его или повесят соответсвующий повышающий коэф на человека с уместным случаю комментарием (т.е. при повторном принятии на страхование застраховаться по стандартным тарифам он не сможет).
Я просто не придумал никакого более надежного способа проверки, чем ручной. Но в реальности, этот способ может быть ужасен: агент хочет продать страховку китайцу (физлицу) — система говорит что пол не верный — продавец меняет пол на тот, который система требует (не отказываться же от сделки?) и никому ничего не говорит. Да будут какие-то отличия в печатном бланке, но авось клиент не заметит.
Я смотрел изредка логи — на каких именах срабатывает проверка. В подавляющем большинстве случаев я был согласен с решением функции, но для части срабатываний у меня не было уверенности. Так что, возможно, ошибок было не 6, а в несколько раз больше. Что, впрочем, тоже довольно неплохо.