Mechanism to control delegation and revocation of tasks in workflow system

A method to revoke a task includes receiving task data, the task data including information regarding a task to be performed. The method further includes receiving delegation data, the delegation data including information identifying a delegator of the task and a delegatee to perform the task. The method further includes receiving revocation task data, with the revocation task data having as its object at least aspects of the task.

FIELD

This application relates to a method and system to revoke a task in application programs, and to a machine-readable medium comprising instructions to perform this method.

BACKGROUND

Tasks or obligations in an application program environment typically depend on the specific application domain. Tasks or obligations may, for example, be the updating of a file in a database, entering a customer's details in the context of opening an account, approving or rejecting a credit application, or opening a legal case.

In the paper-based world, tasks are continuously created, delegated or discharged according to the overall goals of an organisation and the general principles governing the distribution of work within an organisation. These principles would typically comprise a framework for maintaining control over the supervision and responsibility of task completion.

Although workflow products (e.g., the SAP Webflow product), and non-workflow products (e.g., Outlook) support the delegation of tasks, the available delegation functionalities of these application programs are rudimentary. This lack of sophistication often results in uncertainty as to the person responsible for currently performing a task, the origin and ownership of the initial task and the delegation sequence of the task. It may further be difficult for a principal who delegated a task to find out whether a task has, in fact, been completed. Also, the present delegation functionalities provided by application programs may not provide the information required to identify the person who is ultimately responsible to ensure that each single operation in a task has been performed, and may not provide a system-enabled mechanism to handle a situation if each single operation in a task has not been performed.

SUMMARY

According to an aspect of the invention there is provided a method to revoke a task. The method includes receiving task data, the task data including information regarding a task to be performed. The method further includes receiving delegation data, the delegation data including information identifying a delegator of the task and a delegatee to perform the task. The method further includes receiving revocation task data, with the revocation task data having as its object at least aspects of the task.

Other features will be apparent from the accompanying drawings and from the detailed description that follows.

DETAILED DESCRIPTION

According to an aspect of the invention there is provided a method to revoke a task. The method includes receiving task data, the task data including information regarding a task to be performed. The method further includes receiving delegation data, the delegation data including information identifying a delegator of the task and a delegatee to perform the task. The method further includes receiving revocation task data, with the revocation task data having as its object at least aspects of the task.

“Task” as used herein may include a step, an obligation, an activity and/or an action to be performed. The definition of task may depend on the specific application domain.

An example embodiment of the present invention is described below with reference to Use Case and Data models, as well as flow diagrams. The data structure of a task created by an example method is described with reference to a block diagram, followed by a sequence diagram showing the interaction between a delegator, delegatee, data models and other modules of the system of an example embodiment of the present invention. A system diagram of an example embodiment of the present invention is described. Lastly, machine for implementing the method is described in detail.

FIG. 1Ais a diagrammatic representation of a Use Case model of the relationship between a delegator10, a delegatee12and a delegated task14, according to an example embodiment of the present invention. In an application program, whether workflow based (e.g., SAP Webflow) or non-workflow based (e.g., Outlook), the delegator may be responsible for the completion of a task. The delegator may however choose to delegate this task, now the delegated task14, to the delegatee12. Such delegation may be prompted by circumstances such as workload or efficiency.

After delegation, the delegatee12takes over the responsibility for performing the delegated task (shown by16), while the delegator10may remain responsible for reviewing the performed or completed delegated task (shown by18) or at least aspects thereof. This review of the task takes the form of a review task that is created by a review module, according to an example embodiment of the invention and described below. The review task is performed on evidence that is created on the completion of the task and this evidence therefore forms the basis of the review task.

An example implementation of the invention is in the context of a bookkeeping department. An accountant, the delegator, may not be able to process some current invoices from suppliers and decides to delegate the processing of invoices with a smaller value, i.e. the task, to a junior accountant, the delegatee. The junior accountant now is to perform the delegated task and the senior accountant is to review the task that was initially delegated. This review task may take the form of checking that supplier invoices have been entered into the accounting system. Continuing the example, the evidence that is associated with the review task and that may be presented to the senior accountant as evidence that the delegated task has been completed, may comprise an entry for the invoice amount within a general ledger.

Similarly, an example context may be a loan application in a bank. In this example, a “four-eye” principle includes a clerk delegating one or more tasks in a loan application workflow to his colleague. The colleague performs the delegated task, but the first clerk being the delegator or delegating principal still may be under obligation to review the completed task. In this example, the evidence associated with the review task may be the absence of exceptions reported by a control of the loan processing application.

FIG. 1Bis a diagrammatic representation of a Use Case model of the relationship between the delegator10, the delegatee12and a revoked task19, according to an example embodiment of the present invention. The task may be revoked before the delegate12performs the task16, as shown inFIG. 1A, and as described in more detail herein. The revoke task19may be executed by the delegator10in some embodiments. Alternatively, or additionally, any specified principal may execute the revoke task19.

An example implementation of the invention follows the above bookkeeping department example. The senior accountant or delegator may have some free time available and may want to perform the task himself/herself Alternatively, the senior accountant or delegator may want to delegate the task to another principal other than the delegatee12. Further, the delegator may want to revoke the task from the delegatee12in instances where the delegatee12has an illness and/or an absence, in order to allow for continuation of work.

Similarly, an example context may be an incoming customer query received by consultant A. Resolving the query takes certain technical knowledge. Consultant A may not possess such certain technical knowledge. Consultant A may delegate the task of resolving the query to consultant B. In the instance where consultant B is unable to resolve the query, consultant A may revoke the task to facilitate resolution and distribution of the task.

FIG. 2Ais a diagrammatic representation of a business object as used in an example embodiment of the present invention.FIG. 2Bis a diagrammatic representation of a Data model defining business objects, principals in an application program, as well as a structure of a task, as used in an example embodiment of the present invention. Business objects20may include a general set of resources of a company. Business objects20may include a principal22(e.g. delegators10and delegatees12), as well as the task21a principal22is to perform.

Each task21may include a general task25. In an additional embodiment, a task21may comprise the general task25including the specific task26, and/or including more than one specific task26, such that the specific task may be an instance of the general task25. There may be any number of specific tasks associated to one general task. However, in this embodiment, specific tasks are associated to exactly one general task. Such specific task instances are of the same type as the corresponding general task. An example may include the general task to process invoices, while two specific tasks of the same type of general task may include processing an invoice by Accountant A for customer x, and processing an invoice by Accountant A for customer y.

As shown inFIGS. 2A and 2B, specific task instances26are of the type general task25, and the general task25is of the type business object20. Similarly, the delegator10and delegatee12are of the type principal22and the principal22is of the type business object20. The black arrowheads ofFIG. 2Bindicate an inheritance relationship as found in the object-oriented modeling domain.

Each task21may include an application program that may be defined by two objects24or two general attributes:Target object27: the business object (or resource, e.g., an account) that a set of actions defined in the task are to be performed on.Subject object28: the business object (e.g., principal) that has to perform the task. The connection between the subject object(s)28and the principal22is depicted in the illustration ofFIG. 2Aat line28A.

According to these attributes, the subject and target information of the task therefore may define who should perform the task and also may define what resource the task is to be performed on. In the above example, the invoice is the target object, and the accountant A is the subject object.

There may be two types29of principals22: a business role principal30and a particular principal31. Principals may be a target object27of a task or a subject object28of a task. Possible assignments of the task types to the principal types are depicted in lines25A,25B, and26A. The general task25may be assigned to the particular principal31directly (shown by line25A ofFIG. 2A) or may be assigned to a principal over the business role30the principal occupies (shown by line25B). The specific task26or instance may be assigned to the particular principal31directly (shown by line26A). In some instances, specific tasks may be delegated to exactly one principal as its subject object, and may not be delegated to a principal over a business role, i.e. specific tasks may not be shared among principals.

Besides the delegated task or assigned task described above, the review task18and the revoke task19may each also have the two attributes, e.g., the target object and the subject object. The review task18may have the subject object28as the delegator (to review the task) and the target object27as the delegated task (the task to be reviewed). The delegated task may have the subject object28as the delegate12(to perform the task) and the target object27as the task, general or specific (the task to be performed). As shown in more detail with regard toFIG. 5, the revoke task19may have the subject object28as the delegator (to revoke the task) and the target object27as the delegated task (the task to be revoked). The delegated task may have the subject object28as the delegate12(to perform the task) and the target object27as the task, general or specific (the task to be performed).

InFIG. 2B, the general task, relating to the business object20, is associated with and may include a subject object and a target object. There may be any number of subject objects for any general task. Various business objects20may form the target object and the subject object of a task.

FIG. 3is a general flow diagram of a method used in reviewing and/or revoking a task according to an example embodiment of the present invention. In an application program, task data, defining a task to be performed, is received in operation32. This data may be typically entered by a principal via a user interface. Data that may be entered with regard to tasks is described in more detail with regard toFIG. 6.

Delegation data is received in operation33, either via a user interface34or via a delegation module35and database. The delegation module35may include data from a delegation module data (delegation data)104, as indicated in the data structure ofFIG. 6, which includes information identifying a delegator and a delegatee of the task. It will be appreciated that, in the context of the example, the creator of the task may be the delegator.

For example, where a principal decides that a task should be performed by another principal or delegatee, the principal or delegator delegates the task to a delegatee by entering the relevant information via the user interface. This may be an ad hoc delegation. Alternatively, the delegation module35may obtain delegation module data104from the database100, where a particular rule determines that a task should automatically be delegated to a delegatee. An example of such a rule is where a delegator is out of the office and has activated an out of office rule, such that any incoming tasks are automatically delegated. Such an automatic delegation rule ensures that the task is completed without delay, without having to wait for an input from a delegator. It will be appreciated that the delegation module35may find particular application in application programs based on workflow.

The flow chart ofFIG. 3may branch to operation36and/or operation40upon receipt of the delegation data at operation33. The revocation task data may be operated at any time after operation33(receive delegation data) and before the task is completed at operation33(create evidence). A review task is created in operation36, with the review task being assigned in operation37. The review task may be assigned to the delegator to ensure that the delegator retains responsibility for the effective completion of the task delegated. Review module task data (Review data)112ofFIG. 6is created on the creation of the review task operation36and includes, as shown in and described with respect toFIG. 6, review identification information, which is also stored under the task data to directly link the particular review task with the task.

Once the delegatee has performed the task, evidence is created (shown in operation38) as confirmation that the task has been completed. The evidence is directly related to the task, and is typically defined by the review data on creation of the review task. The evidence is now presented to the delegator to enable the delegator to perform the review task. Once the review task has been performed, data on this completed review task is stored in operation39. This data may typically include information on the created evidence and the completed task.

Additionally or alternatively, at a time after the delegation data is received at operation33, the revocation task data may be received at operation40. At operation41, a query as to whether the revocation is allowable is performed. The query includes the method described in detail with regard toFIG. 4. Revocation module task data (revocation task data)110may be received in operation40via a revocation module123, as indicated in the data structure ofFIG. 7.

After verification that the task may be revoked, the task is revoked at operation42. If revocation is not allowable, the revocation is rejected at operation43. Data relating to the revocation task is stored in the database in operation44.

Additionally or alternatively, the delegated task may be manually assigned via the user input34or automatically assigned to a subsequent delegatee by the delegation module35and subsequent delegation data may be received at operation45. The delegation module35may obtain information from the database100to define the subsequent delegator and subsequent delegatee. As described above, the user input is used where a delegator decides that the task should be performed by another person or delegatee. The delegator then creates a delegation path to the delegatee by the user interface. Alternatively, the application program may make use of the delegation module35, which receives the delegation (module) data104from the database100when particular circumstances exist.

At operation46, the subsequent delegation data may be compared to a set of rules (within database100onFIG. 8) to determine whether the delegation is allowable.

For example, the set of rules may include a limitation on the number of subsequent delegations which is allowable. Specifically, certain important tasks may only be delegated once, while other smaller tasks may be delegated three times, for instance. The set of rules may also specify that a review task can never be delegated and should therefore be completed by the respective delegator. In a further embodiment, the set of rules may disqualify the delegator or subsequent delegators from being subsequent delegatees. It is foreseen that other rules may restrict the delegation of tasks within a time period prior to the deadline of completing the task. As further examples, rules may specify that a clerk may only delegate within his branch, or that a senior sales representative may only delegate to staff in his sales region. Other rules may include a limit to the number of times a task may be delegated (depth of delegation chain), and a limit on cycles in the delegation chain, e.g., a task not to come back to the initially delegating principal.

Should the subsequent delegation data that is received not be allowable according to the set of rules, the delegation of the task will be rejected in operation47and subsequent delegation data is stored at operation48. The responsibility of completing the delegated task may then be returned to the original delegatee or to the original delegator (not shown).

In the event that the subsequent delegation is allowable according to the set of rules, subsequent delegation data is stored at operation48and the process returns to the review task created at operation36.

FIG. 4is a flow diagram of a method50to revoke a task according to an example embodiment of the present invention. At operation52, the revocation of the task is requested. At operation55, a determination as to whether the task is completed is made. If the task is completed, revocation is not possible at operation57. If the task is not completed, a determination as to whether the task is to be revoked by the same principal that delegated the task is made at operation56. If the revoking principal is not the same as the initial delegator, revocation is not possible at operation57in this embodiment. If the revoking principal is the same as the delegator, a determination as to whether the task to be revoked is general or specific is made at operation58.

If the task is specific, the specific task(s) are revoked at operation60and at operation62. The return arrow at operation60(and subsequent operations) represents a repeating loop to revoke (or perform) each instance of a task (or each specific task) as part of the revocation process.

If the task is general, a determination is made as to whether assignment of the task was to a principal or over a role at operation59and at operation61. A principal type associated with the delegate may be determined, wherein the principal type is selected from a group including a business role principal and a particular principal. If the general task was assigned over a role, revocation is not possible at operation57. The general task cannot be removed from the business role as this may have an effect on all other role occupants. For example, a general “invoice processing” task is removed from an entire role. The effect includes the entire role being unable to process invoices.

If the general task was assigned to a principal directly, a determination is made at operation63as to whether there are any pending or “existing” specific tasks. Assuming there are pending specific tasks of the general task, e.g., at least some of the specific tasks are not yet completed (as previously determined at operation55), the process is forwarded to operation65.

At operation65, a determination is made as to whether all pending tasks are allowed to be performed or whether all pending tasks are to be revoked individually before the final revocation of the general task. A disposition of pending specific tasks is made, wherein the disposition is selected from a group including revocation and performance completion. If all pending tasks are to be revoked, each specific pending task is revoked in the loop at operation66, and the general task is then revoked at operation69.

If all pending tasks are to be performed, each specific pending task is performed in the loop at operation67, and the general task is then revoked at operation69.

In an example, a principal is transferred to a different accounting division. The principal has a change in roles. However, transfer is only complete after he performs all the currently pending tasks instances. Instances may be pending from the moment they are created and/or from the moment a principal has started the task.

The process ends at operation62where the task is revoked.

Revoking generally may be initiated by a principal responsible for task completion. In contrast, task reassignment generally may be initiated by an administrator.

FIG. 5is a diagrammatic representation70of a structure of a task created according to an example embodiment of the present invention. The target78of the revoke task72is the delegated task80(e.g., the original task that has been delegated). As discussed, this means that the revocation task72is to be performed with respect to the delegated task80, or with respect to at least aspects of the delegated task80. The revoke task72has as its subject74the delegator10, which means that the delegator10is the business object or principal who performs the revoke task80.

Taking a step back, the delegated task80has as its target78the original specific task84, and has as its subject86the delegatee12. From the attributes of a task defined above, this indicates that the delegated task80is to be performed by the delegatee12and that the task to be performed is the task84.

Once the delegated task80is revoked by the delegator, a revoked task86is produced. This revoked task86may be evidence88of the task revocation. The evidence88may be directly associated with the task84, indicating that this task84has been revoked. The evidence88may be presented to the delegator10and may form the basis of subsequent delegation by the delegator10or performance of the task by the delegator10. The evidence88ensures that the delegator10is in a position to perform his obligation of making sure that the delegated task80is facilitated and distributed appropriately.

FIG. 6is a block diagram showing the data structure for task data, delegation module data, revocation module task data, and review module task data, as used in an example embodiment of the present invention.

Delegation module data (delegation data)104further includes information identifying a delegate, who takes over the responsibility to perform the task. The delegation data104also includes delegation identification data (stored under the task data) and delegation details, such as the date and time when the task was delegated. A delegation ID may also be assigned to each delegation instance.

General task data106of the task includes task identification data (e.g., the name or ID of the task) and a task description (e.g., the set of instructions to be completed to perform the task). The general task data106further includes data identifying the subject of the task (e.g., the principal that has to perform the task), and data identifying the target of the task. As mentioned above, the target of the task may be the business object or resources on which the set of actions defined by the task is to be performed.

Further information included in the general task data106may be the start date, due date and owner of the task. As will be explained later, the general task data106also includes delegation data identification information that is used to link possible future delegations and the respective data of such delegations to the task. Review task data identification information and/or revocation task data identification information may also be included in the general task data106, similarly to link associated review and/or revocation task data to the task.

The specific task data108of the task includes task identification data (e.g., the name of the task) and a task description (e.g., the set of instructions to be completed to perform the task). The specific task data108further includes data identifying the subject of the task (e.g., the principal that has to perform the task), and data identifying the target of the task. As mentioned above, the target of the task may be the business object or resources on which the set of actions defined by the task is to be performed.

Further information included in the specific task data108may be the start date, due date and owner of the task. As will be explained later, the specific task data108also includes delegation data identification information that is used to link possible future delegations and the respective data of such delegations to the task. Review and/or revocation task data identification information is also included in the specific task data108, similarly to link associated review and/or revocation task data to the task.

Revocation module task data (revocation task data)110may be created on the creation of the revocation task and includes, as shown in and described with respect toFIG. 6, revocation identification information which is also stored under the task data to directly link the particular revocation task with the task. The revocation module task data110defines parameters for revoking the task. The revocation module task data110further includes data relating to a duration or timeframe for completing the revocation task.

Review module task data (Review Data)112is created on the creation of the review task and includes, as shown in and described with respect toFIG. 6, review identification information which is also stored under the task data to directly link the particular review task with the task. The review data112defines parameters for reviewing the task (e.g., the evidence that should be presented to the delegator). The review data112further includes data relating to a timeframe for completing the review task.

FIG. 7is a sequence diagram showing the interaction between the delegator and delegatee, different data models, a review module, and a revocation module, according to an embodiment of the present invention.

Turning now toFIG. 7, a sequence diagram illustrates an operational sequence, according to one example of the present invention. This sequence diagram shows the interaction between a delegator10, a delegatee12, a data model for the task120, a data model for the review task122, a revocation module123, a review module124, a data model for the revoke task125, and a controller127. The interactions are shown as interaction between the principals130, review module activities140and revocation module activities150. The delegating principal (delegator10) delegates132a task to the delegatee12. The delegatee may perform134the task or the delegating principal may revoke151the task before completion as described further with regard toFIG. 7.

The interaction between the principals130commences with the delegator10delegating132a task, now the delegated task, to a delegatee12. After the delegatee12has performed134the delegated task, the delegator10may review138the completed task, i.e. the delegated task.

The review module activities140commence with a review task being assigned142by the review module124. During this assignment, the review module124sets144the delegator10as the subject of the review task and further sets146the delegated task as the target of the review task. Once the delegated task has been completed by the delegatee, the controller127is informed of the completion148. The controller127then demands149that the review task assigned to the delegator is performed138by the delegator10.

Again, it will be appreciated that a delegated task may be delegated, by a delegatee, to further or subsequent delegatees. An example of a further delegation includes an incoming customer query to be resolved by a consultant A. In the circumstances, consultant A may not have the required technical knowledge to effectively deal with the query (or portion of the query), and he therefore delegates the task (or a portion of the task) to a further consultant B. This further consultant B may in turn also not be able to resolve the query and delegates the task further to consultant C. In the present example, two review relationships (and review tasks) are created, the first between consultant A and B, and the second between consultant B and C. The review tasks again seek to provide accountability in the process of delegation, even where tasks are further delegated.

It will be understood that all delegations, but in particular subsequent delegations, may be enforced according to a set of rules that may either allow or reject a subsequent delegation. The rules typically depend on the organisational context of the delegation Examples of rules are discussed herein.

The revocation module activities150commence with a task being revoked151by the delegator10. The controller is informed152about the revocation. During this process, the revocation module123verifies154that the revocation of the delegated task was assigned by the delegator10. The interaction between the respective data models and other modules form part of a system, which is described in further detail below with reference toFIG. 8.

FIG. 8is a block diagram showing a system160to create a review task and a revocation task, according to an example embodiment of the present invention. This system160comprises a task management application161and a database100, the database100containing data relating to the task106and/or108, data relating to delegation of the task104, data relating to the revocation task110, and review data112.

The task management application161has a user interface166that may be used by a principal162to input data for use by the task management application161. For example, the delegator may use the user interface166to input task data relating to a task to be performed. The user interface166may further be used by the delegatee to complete the task or may be used by the delegator to complete the review task.

A program interface168also forms part of the task management application161and is used to connect the task management application161to a second application or system170. The task management application161may either be interfaced to a second application or system, or may alternatively form a part of Enterprise Resource Planning software, such as SAP or other applications.

A task creation module172of the task management application161receives the task data relating to a task to be performed and creates a task based on the received information. The task may be general or specific.

The task management application161may also receive (or generate) data relating to the delegation of the task. This data may be received via the user interface166, in which case the user interface166is used by the delegator to identify him- or herself as the delegator of the task and also to identify a delegatee to perform the task. In this example the delegator commissions an ad hoc delegation task

Alternatively, delegation data may be received via the task delegation module174, which receives delegation data identifying a delegator and a delegatee to perform the task. This information is received from the database100in which delegation module data are stored. As mentioned, the task delegation module174is used where a particular rule determines that a task should automatically be delegated to a delegatee. Automatic delegation rules ensure that tasks are completed without delay.

The task management application161further includes a review module176that creates a review task with at least aspects of the task being the object of the review task.

The task management application161further includes the revocation module123, which sets the delegator as the subject of the revoke task.

As mentioned, the system160further includes the database100. The database100stores the task data, delegation task data, revocation task data, and review task data. The database100is also used to store the set of rules that govern delegations, and in particular, subsequent delegations. Task modulation data is also stored in the database.

The data stored in the database is used whenever information is required regarding details such as the person responsible for currently performing a task; the origin and ownership of the initial task and the delegation sequence of the task. Such information may be presented in the form of a task report, which contains information on the task, delegators and delegatees, evidence on the completion of tasks, and other delegation information.

It may be appreciated that the role-based Enterprise Resource Planning workflow system described herein distinguishes between general and specific tasks, and their relationship to business roles. A task revocation algorithm is generated according to the general and specific tasks, as described herein. This workflow system may be changed at runtime through the delegation and revocation of general tasks, thus supporting organizational change without stopping the system and/or without having an administrator revoke the task or delegate. The delegation and revocation of tasks may be performed on the basis of a defined delegation and revocation protocol, and supporting delegation and revocation engine (such as the delegation module and the revocation module).

The example computer system200includes a processor202(e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory204and a static memory206, which communicate with each other via a bus208. The computer system200may further include a video display unit210(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system200also includes an alphanumeric input device212(e.g., a keyboard), a user interface (UI) navigation device214(e.g., a mouse), a disk drive unit216, a signal generation device218(e.g., a speaker) and a network interface device220.

The disk drive unit216includes a machine-readable medium222on which is stored one or more sets of instructions and data structures (e.g., software224) embodying or utilized by any one or more of the methodologies or functions described herein. The software224may also reside, completely or at least partially, within the main memory204and/or within the processor202during execution thereof by the computer system200, the main memory204and the processor202also constituting machine-readable media.

The software224may further be transmitted or received over a network226via the network interface device220utilizing any one of a number of well-known transfer protocols (e.g., HTTP).

While the machine-readable medium222is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. Although an embodiment of the present invention has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.