Greeceman

Эх, читаю ответы и грустно становится. Как говорил мой начальник (на которого я до сих пор работаю) "У меня было много работников, и опытные, и которые только обучались, но никому работа не приносила удовольствие. Они делали это потому что надо, а не потому что хотели."
А как говорил Конфуций: "Выбери себе работу по душе, и тебе не придется работать ни одного дня в своей жизни"
Так вот, я лично занимаюсь IT потому что мне это нравится, это интересно, увлекательно. Да, за бесплатно пахать 8 часов каждый день никто не будет, но деньги вообще не главное в этом профессии, особенно когда и так средняя ЗП хорошая и грех на неё жаловаться.
Я считаю огромным плюсом, это то, что работая IT специалистом, ты можешь посещать другие компании, побывать в них, посмотреть что они делают, как это все работает изнутри. Недавно я конфигурировал сервак за 350к рублей, без надобности покупать его, это же прикольно держать в руках и иметь дело с такими дорогими вещами, не покупая их.
Вообщем мнение своё высказал, а людей которые делают свою работу, лишь потому что это работа, жалко.
Желаю всем найти работу по душе, чтобы вы могли совмещать хобби и работу.

Через таблицу линковок внешних и внутренних полей.

Таблицы:
1. Список поставщиков данных (id, название, ...)
2. Список полей внутри вашей системы для внешних данных (id, название_поля, назначение, .....)
3. Поля поставщиков (id, id_поставщика, конкретное_входное_поле_поставщика, описание_поля, regex-фильтр, количество_ошибок_фильтра,....)
4. Линковка полей (id, id_поля_поставщика, id_поля_в_вашей_системе, когда_слинковано, кем_слинковано,....)

Сделайте описание как вы отличаете джунов от мидлов и вопрос отпадет сам собой, а если вы их не можете отличить формально, то вопрос не имеет смысла

У нас в компании недавно сделали открытые требования к грейду. Младший спец должен делать узкий круг задач, но под контролем своего руководителя. Чуть выше грейд- это уже самостоятельный чел. Старший спец - это уже тот кому может потребоваться делегирование своих полномочий. Т.е уже выше уровень. Ещё выше ведущий специалист. Так же идёт расчёт, работник движется в сторону менеджера или тех спеца. К примеру Тим лид - это больше менеджер и движется в управление. Тех спец движется в сторону консультанта и архитектора. Каждому сотруднику задаются цели на год. Потом проводится аттестация по результатам. Как правило цели выбираются для достижения грейда и зарплаты.

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

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

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

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

обычно крупные компании пишут CRM сами или обращаются к интеграторам-автоматизаторам.

Но обычно когда компания реально крупная - писать самим, т.к. постоянно процессы добавляются, изменяются.
Если все это делать силами интегратора те же десятки миллионов будет стоить, только в итоге вы будете без свой системы и своего кода.

Можно начать со стандартного каркаса

Классы (id, название)
Ученики (id, имя, id_класса)
Предметы (id, название)
Оценки (id_ученика, id_предмета, оценка)
Таблица оценок одновременно является таблицей связи Предметы <=> Ученики

Можно попробовать операться на флексии в названии объекта. Для их выделения придется набросать какую-то библиотеку, а за основу взять любой стеммер. Если делаете на js то есть яндексовский стеммер быстрый и простой.
Лучше всего опираться на аффикс-стеммер.
Когда у вас будет суффикс слова потребуется выделить из него окончание. Это уже совсем просто, а если у вас аффикс-стеммер, то окончание где-то в нем уже будет выделно.
Ну а дальше правило частично подбирается из вашего же примера - окончание "ая" для объектов женского рода - тип добавляем в конце. Окончание "ого" для объектов мужского рода - тип в начале.
В названии содержится слово "имени" или "им." тогда тип ставится перед ним.
И так далее - вам будет нужна таблица окончание/тип объекта и на пересечениях положение типа относительно названия.
Это будет основной способ.
+ будет предварительный - если название из двух или трех слов и содержит слово "имени".
+ таблица особых случаев через которую вы зададите немногие исключения (которые вероятно будут).