#30 - на мой взгляд все выводы поста, скажем так, "необычные".

1 - для современных систем ввода-вывода табличный(двумерный) вид самый удобный. Форма, показывающая одну запись слишком ограничена для ввода и просмотра, ИМХО.
2 - в Вашем случае альтернативы просто нет. Или Вы хотите вводить все контакты в одно поле? Это точно неудобно, и для ввода данных, и для их выборки/анализа.
3 - более тяжелое? Тогда Вам надо купить пачку "желтых листочков" и сделать из своего монитора "ромашку", тогда Вы поймете что такое "тяжелое решение". БД для того и придумали, чтобы эффективно хранить и обрабатывать данные и очень жаль, что эксель в стандарте не поддерживает полноценную работу с БД!

ИМХО, странное резюме напрашивается по данной теме. ТС либо издевается, либо плохо понимает русский язык. Эксель, как способ ввода данных, достаточно продвинутая программа. Куча возможностей по проверке вводимых данных и автоматизации. Одно простое копирование строк очень эффективно позволяет заносить/заменять данные в таблице хранения, не говоря о макросах и UDF! И хранение данных до какого-то объема тоже позволяет организовать. А вот противоречие между вводом и хранением данных - это .... как противоречие между круглым и зеленым, ну ведь совершенно разные задачи!

Резюмирую: то, что описано в #1, давно имеет решение (см. любую CRM), но ТС они не нравятся из-за какого-то противоречия, которое сам ТС сформулировать не может. Возможно, это верная постановка вопроса, но не в рамках этой темы форума, ИМХО. Здесь рассматриваются конкретные, практические задачи, поэтому третий раз советую автору темы сделать файл-пример и показать, каким д.б. результат.

Я уже говорил, что проблема, так скажем, не в реализации, а в архитектуре. Смысл моего поиска как раз в том и состоит, чтобы понять ЧТО именно реализовать. Сейчас мне это уже более-менее понятно.
Да, решение (общее) есть. Но если вы внедряли CRM вы наверняка знаете, что ни одна CRM не бывает сколь-нибудь удовлетворительно заточена под нужды и процессы компании. Именно поэтому их так много. При выборе CRM почти всегда натягиваешь либо имеющийся функционал на свои процессы, либо свои процессы на имеющийся функционал, и не всегда то или другое выходит удачно.

Почему нам сейчас не подходит CRM я могу сказать кратко — очень много процессов УЖЕ опирается на эксель (который появился, как быстрая и простая альтернатива бумажечкам). Да, я могу сесть и написать CRM, идеально заточенную под нужды нашей организации, но это дорогое решение: месяц моей работы уйдет на создание прототипа, и еще полгода на допиливание и докручивание. Поэтому сейчас мы идем по пути самых простых решений.

Именно! Это разные задачи. Поэтому и возникает противоречие. Потому что в данном случае нам нужны свойства СУБД, а эксель — не СУБД. Если таблица одна, и запись хранит данные об одном клиенте — это концептуально самая простая модель. Она понятна и доступна для мало-мальски знакомых с экселем. Удобно заносить данные: ткнул в пустую строку и вводишь последовательно в поля имя, телефон, и все остальное. Визуально удобно выявлять строки-клиенты, которые предстоит обработать. Удобнее выполнять поиск и перенос обработанного клиента.

А если одной записи (строке) таблицы сопоставляется попытка контакта с клиентом — то да, без сомнения эта структура способна адекватно отразить хоть 1000 таких попыток. Но работать с ней реально неудобно: чтобы обновить статус, придется дублировать всю запись — лишние действия и, как следствие, возможные ошибки. Как отобрать клиентов по последнему выставленному статусу? В принципе можно, но надо заморочиться и делать отдельное представление (таблицу), которое будет анализировать поле статуса и дату-время каждой записи. Значит появляется еще одна сущность. Удалять/переносить зафиналенных клиентов — тоже нетривиальная задача. Этот вариант — шаг в сторону, когда хранение данных отдельно, интерфейс отдельно. Т.е. это шаг в сторону СУБД.

О нет-нет-нет-нет-нет!!! Никакого копирования! Наши талантливые девы такого накопируют — фиг найдешь концы! Плавали, знаем )))
Только выбор поля ввода (табличного или пользовательской формы) и только ввод (ну, или корректировка значения). Может это излишняя паранойя, но практика показывает, что любое действие, где потенциально можно совершить ошибку рано или поздно к этому приведет. Поэтому я стараюсь минимизировать это настолько, насколько разумно возможно.

Для ввода самое то. Для работы со списком — отдельное представление данных.

Тяжелое — имеется в виду, затратное по ресурсам и времени разработки. Эксель + БД разумеется тяжелее, чем просто эксель )))
А ромашки из бумажек мы проходили. И отказались от них в том числе благодаря Экселю.

Я благодарю всех, кто высказал свои мысли и идеи. Склоняюсь к решению на основе пользовательских форм ввода.

 

Я работал в компании - CRM была майкрософтовская Dynamics. На ее допиливание под нужды компании был создан целый отдел. То что вы хотите сделать в Эксель это временная заплатка, т.к. со временем возникнет потребность увеличения функционала, которые решить средствами Эксель уже не удастся, соответственно встанет вопрос с переносом базы в другую программу. Я считаю, что лучше сразу сделать правильно и в программах, предназначенных для этого.
Из опыта анализа контактов. Реально читаемым является один контакт-одна запись в БД.
Для реализации в Эксель можно придумать базу контактов, девочка операционист выбирает клиента, затем вид контакта (звонок, встреча, письмо) перед ней открывается окно ввода данных (дата, о чем договорились и т.д.), эти данные хранятся например на другом листе, и для анализа средствами VBA вытягиваются на третий лист необработанные контакты

Т.е. Вам нужна идея: как визуализировать в эксель связку Клиенты-Контакты, причем существующие способы CRM не использовать?

Хотя нет, есть же в #1А в #31 приведен пример решения. Остается только один вопрос: чем не устраивает? Ответ видимо в этом:(Как будто ввод данных в одно место гарантирует минимум ошибок!)

Уважаемый автор, Вы не могли бы сформулировать проблему более точнее?

Да, разумеется, это решение на коленке.

Да, что-то типа этого я сейчас делаю )))

Не, щас вроде бы вырисовалась оптимальная схема: форма ввода и VBA-код, который растаскивает данные по таблицам. И т.д.Это вариант. Сейчас делаю нечто подобное. Разумеется, своя форма и своя логика, но суть примерно такая же.

Под вводом данных в одно место я имею в виду прежде всего ввод в одну строку одной таблицы. И да, это минимизирует количество ошибок.

Потому что если перед тем, как создать запись-контакт, надо сначала внести запись в список клиентов, а потом уже из этого списка «выбирать», скажем, выпадающим списком, то с точки зрения программиста — это все очень логично: вот справочник, вот журнал. А на практике это жутко неудобно и люди по факту используют плейн текст. Да неструктурировано, но проще всего. Поэтому я ищу альтернативу, которая будет сопоставима по удобству ввода: либо последовательное заполнение полей таблицы, либо заполнение формы (что предпочтельнее).

В настоящее время картина более-менее вырисовалась. Хотел обойтись чистым экселем, но, видимо, все равно придется подтягивать тяжелое вооружение в лице VBA.

Спасибо за хороший пример. Взял за основу.

ИМХО, дело не в том куда и как вводить (ведь можно клиента добавлять по-умолчанию), а в логике данных. Кто-то должен проверить, что клиент не задвоен название введено верно, и проверку должна делать точно не программа. Вам нужно описать для себя этот процесс, затем уже пытаться его реализовать.

Тогда чего Вы от форумчан хотите? Ведь этих процессов они не знают, а Вы им их не рассказываете.

Сейчас пока на коленке автоматизирую, потом нормальную CRM запилим )

Читаю эту тему, и никак не пойму...
Вопрос
Архитектура данных: как хранить историю взаимоотношений с клиентом
Ответ
В виде плоской таблицы.

Какое отношение вся писанина на 2 страницы имеет к вопросу?
При чем тут ввод и обработка данных?

На самом деле все зависит от предполагаемого объема информации.
Если клиентов в год будет штук 5, то можно и в ворде, и в блокноте (даже в бумажном) )
В интернете полно небольших бесплатных crm, как облачных так и декстопных с вполне нормальным функционалом.
Если хочется больше и лучше, ищите нормального спеца, который сам Вам все сделает. Потому что переделывать после Вас будет дороже.

Ну не знаю. После спеца тоже сложно что либо переделать. Да после любого программиста сложно что-то переделывать, так как что именно там нахавожено знает только он. Так что я думаю, надо всегда быть в курсе сложных решений, ибо спец потом умрёт или уедет, а программа останется недопиленной.