it depends on what you understand under enterprise knowledge.
If you just understand the terminology used in the organisation and by their customers, a thesaurus may suffice. If you understand a large body of factual knowledge with a common organisational interpretation a knowledge graph will be the best choice, combining a the large fact base with a light weight ontology.
If you need to integrate different information source, an ontology as a formalization of mapping rules my help. If you need to represent definitions and ensure their consistency than a description logical ontology should be your choice. If need extensive derivations of factual informations, than some rule-based representation is your best choice. And if you need to derive probabilistic knowledge about possible events, than I would suggest to use Probabilistic Graphical Models.
So you see it would be much easier to answer you question if we would know for which purpose you like to represent the enterprise knowledge.
In addition to Thomas answer, it would be also helpful to know why ontologies shouldn't be used. Try to go one step back and think about your problem, which you would like to solve and what you would like to achieve tackling this problem.
The two main alternatives I see are databases and object model (for example in UMLS). Both can represent and store knowledge, with advantages and drawbacks compared to ontologies.
Databases are better regarding performances (huge volume, fast access). Object models are very easy to implement in any object-programming language and very versatile. Ontologies are more expressive : they can express more complex and sophisticated knowledge.
In addition, some tools exist for storing ontologies in databases and/or generating object model from ontologies.
Thank you all .I am not against using ontology , but I'm gathering some information to make a comparative between the techniques of knowledge representation in enterprises.
again, thank you that was very helpful
Thomas Hoppe, Andreas Bildstein and Jean-Baptiste Lamy .