Private blockchains can be seen as a new method for ensuring consistency in a distributed database, even if that database is an environment of perfect trust. There is an equivalence between how a blockchain prevents two transactions spending the same prior transaction output, and how multiversion concurrency control (MVCC) in a relational database prevents two transactions modifying/deleting the same database row. (From the perspective of the MVCC storage layer, there is no such thing as modifying a row in place.)
This means that a private blockchain can provide the same kind of concurrency control as MVCC, but in a distributed database which can be written to from many different locations simultaneously (multi-master replication). A blockchain is certainly not an ideal solution for all scenarios like this, but if the row size is small, transactions affect few rows, and conflicts only happen if someone is misbehaving, a private blockchain can maintain provable consistency (through a single hash!) across many nodes of a distributed database, all of which can write to the data.
When it comes to maintaining a shared database between entities with imperfect trust, private blockchains have some great additional features:
The database can contain application logic in the form of constraints on valid transactions. This kind of constraint goes beyond regular database stored procedures because it cannot be circumvented under any circumstances.
The database has per-row permissions which use public key cryptography. Furthermore, every transaction presents a publicly auditable proof that its creator(s) had the right to delete/modify its prior rows.
Of course, not by coincidence, these are very relevant features for inter-company financial ledger databases.
There's a more detailed explanation in my post: Ending the bitcoin vs blockchain debate.