Modeling is an abstract description of a complex system or process, typically in the form of a diagram plus supporting attributes. The description is based on a particular perspective of the system or process, and the same system or process may support more than one. For example, a single process can be modeled from the perspective of activity flows, state transitions, data flows, use case interactions, or in other ways. Each model describes the system in terms of elemental concepts that are inter-related as specified by a metamodel.
Modeling is "abstract" in that the model can suppress detail not needed by its particular perspective. A modeled system or process is not necessarily efficient or effective. If modeled correctly, it just means the description is accurate.
Not all modeling notations and their respective metamodels are based on standards. Many are specific to a particular tool or methodology. Standards-based modeling notations, however, extend the range of shared understanding and generally lower the cost of the modeling tools. Examples of standard modeling notations include the Business Process Modeling Notation (BPMN) and Unified Modeling Language (UML).
In BPM, modeling is used in a variety of ways, and the meaning of the term depends somewhat on the audience. Process modeling usually implies a business-oriented description of the process in terms of activity flows (flowcharts) that supports analysis, but not necessarily executable implementation. BPMN is a good example of this type of model. In that context, the process model is distinct from the implementation design, which uses an alternative technical description of the process. In some tools, such as IDS Scheer ARIS, the process model is just one of many models interlinked in a larger modeling framework. Those other models describe data, services, physical systems, organizational units, and additional aspects of the business, and define the relationships between them.
Developers also use models such as UML diagrams to create executable implementations of systems and processes. An ongoing effort by the Object Management Group and others in the developer community, called Model-Driven Architecture (MDA), seeks to automate the generation of executable code directly from the model.
Modeling of course goes far beyond just modeling the process. Modeling also includes the definition of objects and the way they are persisted and where they get their data from. In a programmer's world this can be the Entity Relationship Diagram, the tables and their relations in the underlying database, or the web services, function calls and APIs. In a process world these objects are the Lego-bricks for building your business processes.
Luckily for us, multiple tools like Composite Application Framework, MDM or SAP BI offer modeling tools that allow defining objects abstracted from the database scheme. An attribute in one case, might be its own full object in another industry. Functionality like language independency of texts, hierarchies, GIS enablement or time dependency with these tools is often only a checkbox, but influences the database scheme tremendously.
Depending on your modeling decisions, the performance, the future extensibility or the usability of your application can be influenced heavily by this. And what's one industries' state-of-the-art modeling is another industries' absolute no-no. Which foreshadows your skill set: modeling is fine, but without knowledge about the business you are working in, it's worthless.