bpmbusinessmanagementstandardizationstandards
There are several approaches on how to model a business process in software applications (BPM software). For instance, a processes can be described in BPMN, EPC, IDEF0, SOMF, etc.
Additionally, different process execution languages such as BPEL, RPC, Wf-XML are available.
If I were to develop software for the BPM-market, which standards should I implement or focus on? Which standards are most suitable if my BPM software was going to be implemented in my client's IT-System?
Your primary difficulties I feel are that you have a mismatch between a very linear and custom workflow in an older application that do not coincide with the user interaction workflows that are common on the web.
Web applications that interact with a server application that contain the business logic communicate in a Request/Response messaging style. The client browser and the server running an application that has the business logic are separate processes. The client requests a resource (html page, jpg image, JSON data, etc...) and the server provides that resource in an inherently stateless way. This is a much different paradigm from your self contained desktop application that has a concept of global state for a users session. The users session in a desktop application lives and dies by the running process on the workstation.
So basically there are two ways you can handle the maintenance of state in a web application that always has a client/server relationship.
A server centric web application will maintain stateful information for an individual user's session. They do this typically by serving a session cookie once the user is authenticated. The client application (browser) will include its unique session token with each request which allows the server to retrieve stateful information about the clients state from the last time they received a request for this client.
Further the server will contain most if not all of the business logic behind performing actions that the typical business user will want to achieve, actions that have real business value. This is not to be confused with presentation logic which is most client side code (Eg. Javascript) that performs user interface interaction like hiding a particular menu in a form if a specific checkbox has been checked.
While you might have a server to maintain authentication of a user and maintaing an active session, you could use a client side scripting framework (Eg. Javascript framework like AngularJS to perform most if not all of the business logic operations and presentation logic operations. The advantages of this model are that you can program your web application in much the same way as one might program a desktop application. Client state will live and die by the browser navigation to the current page in much the same way that it will live and die on the running process of a desktop application. For communication with a database you can expose stateless webservices on the server that can proxy for a database.
Some important considerations with this approach are that users on client browsers have the ability to modify or change how Javascript can behave which might be potentially dangerous and introduce unknown exception cases to your application. It is highly recommended that if this approach is taken that great care should be taken on interactions with servers to sanitize inputs and validate all data going back and forth.
In summary, the application you specified is very old. It sounds like you are making the right choice in capturing the current workflows and trying to assess what the user needs are. The next step would be to try and follow Agile principles and capture business value in user stories. I would start on clean slate and try to discover other means and workflows that can also attain the same business value captured in the user stories. This application is so old that it was likely limited by the technology of its day to where technical constraints influenced the user workflows in a negative or archaic way. Basically there are probably better ways, more intuitive workflows and user interfaces that the business can use that will also achieve the same end goals.
BPMN is a profile which extends the UML language for a certain domain. Like with natural language you have a different wording to express things. And sometimes the same phonemes even have different semantics. So you need a bit of care when using both languages the same time.
BPMN is different to use cases as it focuses heavily on functionality. It has lots of new words that can describe how things interact. Use cases in contrast primarily aim to describe the added value, a system delivers to an actor. So that's something very, very basic. Use cases also have means to express how process steps are executed (using Activities and Actions). You find the same in BPMN and for the very same purpose. But, where Use Cases end, BPMN will start. So it's a good idea to gather the added value with use cases and then use BPMN in the following phases to describe how scenarios in use cases can be mapped to business processes (means order of actions in activities).
It is noteworthy that UML is not about diagramming, since this is mistaken by many people. There are a couple of different diagrams defined in the UML 2.5 spec for certain sub-domains. So you can expect a set of elements to appear in specific diagrams. But that's not mandatory. You can mix any elements if it helps communication the model (which is what holds the semantic). The diagrams are just meant to help people understand the model. So UseCases as per spec are (p. 637)
a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase’s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors.
A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.
And you will find the previous elements most likely in Use Case diagrams. However, you are free to mock them up where needed. So mixing BMPN (or elements from other profiles) is absolutely possible.
From the annex (p. 683):
NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.
Best Answer
If you are going for an Enterprise market, taking an approach similar to IBMs might be useful.
See Business process standards, Part 1: An introduction which includes a short section on the relationship between the standards and Business process standards, Part 2: How the standards are used in WebSphere products which describes specifically how IBM incorporates them into their own products.
There is also Modeling Standards Supported by ARIS which includes the standards they support and pointing out that each standard is focused for
I believe that the full answer to your question depends on who you want to pitch your software to. A BA likely to model the process at a higher level than an Architect, who will likely want to specify some implementation and possibly shares some interest in code generation with the developer, who probably cares mainly about the execution.