Which is the same thing I already said, but with different names for the steps.

However, I have seen "simple" business model changes that required almost complete redesigns of the database. For example, it's usual to have a one-to-many relationship between orders and customers, and a one-to-many relationship between orders and shipments. I.e., you don't normally have two or more customers assigned to a single order, and you don't normally have two or more orders on one shipment; but it is normal (salespeople hope anyway) that each customer will have multiple orders, and it's common to break orders up into multiple shipments.

That's how a business I worked for operated for years. Then, because of a new product line, it became necessary to consolidate multiple orders into single shipments that would be for multiple customers, in some cases. So, some orders would be split into multiple shipments, for one customer, some would have one shipment for multiple customers, some would have multiple shipments for multiple customers on one order, and so on. This was necessary to handle certain product lines and certain inter-business ordering practices.

Well, that required a huge revamp of the whole data model, because of a single product line that was introduced, but without any change to the core business.

Rare, but it can happen.