In BPMN Data Modeling is used for such aim. In process modelling it is essential to model the items (objects) which are manipulated and used during the execution of the process. The most common element for doing this in BPMN is Data Object, which is typically pictured like this
According BPMN 2.0 specification:
The primary construct for modeling data within the Process flow is the DataObject element. A DataObject has a well-defined lifecycle, with resulting access constraints.
The Data Object class is an item-aware element. Data Object elements MUST be contained within Process or Sub- Process elements.
Moreover, if we stick to your question, there is special attribute of Data Object which is called DataState. According the specification:
Data Object elements can optionally reference a DataState element, which is the state of the data contained in the Data Object. The definition of these states, e.g., possible values and any specific semantic are out of scope of this International Standard.
As you can see, these states are not well-documented and implemented not by all vendors. For example, Camunda supports it.
Another approach that often works is to name the activities using verb-noun combinations that describe the state change. If "Ship order" has been completed (and there is no gateway with loopback) the state of the order can be inferred to be "shipped".
I see BPMN processes as primarily activity-oriented. Activities are expressed directly, whereas object state is often expressed indirectly. A BPMN process diagram is not a state diagram. (The difference has been the topic of several discussions between me and business analysts etc used to modelling state for classic data-centric applications.)
